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ABSTRACT 


This  thesis  exaaines  the  structure  and  functions  of  a 
generalized  tactical  intelligence  collection  system. 
Included  are  its  position  in  the  intelligence  system  struc¬ 
ture,  relationship  with  other  activities  in  the  intelligence 
system,  and  the  orgarizaticn  and  control  of  its  components. 
A  mathematical  optimization  model  of  a  simplified  intelli¬ 
gence  collection  system  is  developed  to  explore  several 
issues  related  to  intelligence  collection.  An  interactive 
multiattrifc ute  decision  aid  useful  in  the  prioritization  of 
numerous  intelligence  collection  requirements  is 
demonstrated. 
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I.  INI BOPDCTIOH 


A  great  deal  of  effort  has  been  expended  in  recent  years 
concerning  the  management  of  large  quantities  of  battlefield 
intelligence  information.  The  presumption  of  such  concern 
is  that  vast  amounts  cf  information  will  be  collected  during 
the  ccurse  of  the  future  battle.  The  deployment  of  numerous 
collection  platforms,  sensors,  and  the  like  does  suggest 
tnat  there  will  indeed  be  a  deluge  of  information.  Eut  will 
this  information  be  cf  value  to  the  decision  maker? 

Cne  way  to  insure  that  collected  information  is  cf  value 
is  to  manage  those  collection  platforms  in  an  intelligent 
manner.  This  implies  that  their  operation  should  be  ccntro- 
lable  and  efficient.  This  thesis  will  develop  the  physical 
and  functional  structure  of  a  generalized  intelligence 
collection  system  with  the  idea  in  mind  of  improving  the 
control  and  efficiency  of  its  collection  platforms.  It  will 
analyze  the  components  of  this  collection  system  to  deter¬ 
mine  where  modern  management  tools  can  be  applied  tc  the 
collection  management  process. 

Chapter  Two  introduces  the  generalized  intelligence 
system  structure  and  describes  the  relationships  between  its 
major  subsystems  -  the  requirements  system,  analysis  system, 
collection  system,  and  dissemination  system.  It  addition¬ 
ally  highlights  the  role  the  intelligence  requirement  plays 
in  the  intelligence  system.  Chapter  Three  focuses  upon  the 
intelligence  collection  system  to  include  its  structure, 
functions,  and  considerations  which  make  the  effective 
management  cf  the  system  such  a  difficult  task.  Chapter 
Four  analyzes  the  critical  component  of  the  collection 
system  -  the  intelligence  collection  requirement  -  in  great 
detail.  It  focuses  upon  the  sources  of  the  collection 


requirement  and  the  traditional  flow  and  management  cf  the 
requirement  in  the  collection  system.  Chapter  Four  addi¬ 
tionally  developes  a  sore  analytical  aanner  in  which  collec¬ 
tion  requirements  car  be  decomposed  into  smaller  elements 
and,  based  upon  this  process,  suggests  a  restructuring  of 
the  traditional  collection  system.  Chapter  Five  develops  a 
mathematical  optimization  model  of  the  collection  management 
process  and  explores  variations  of  that  model  which  are 
useful  in  the  understanding  of  the  collection  management 
problem.  Chapter  Six  illustrates  how  the  models  developed 
in  the  previous  chapter  can  easily  be  modified  to  the  real¬ 
istic  collection  management  environment.  Finally,  Appendix 
A  demonstrates  a  multiattribute  decision  making  approach 
toward  the  prioritization  of  collection  requirements 
according  to  current  or  envisioned  battlefield  conditions. 


II.  A  GEN EEAIIZE D  INTELLIGENCE  SYSTEM 

A.  INTRODUCTION 

Any  tactical  intelligence  system  can  be  described  in 
terms  of  its  major  functional  systems.  These  systems 
include  the  following: 

-  Requirements  System 

-  Analytical  System 

-  Collection  System 

-  Dissemination  System 


Analytical 

Syataa 


Aaqulraaanto 

Syataa 


Co n act  Ion 

Syataa 


_ loading  Flo* 

_ Information  Flo* 


Figure  2.1  Generalized  Intelligence  System. 

The  focus  of  this  chapter  will  be  to  examine  seme  of  the 
generalized  characteristics  of  the  first  two  of  the  systems 
listed  aiove.  Because  of  its  key  role  in  the  collection  and 
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analytical  process,  particular  attention  will  be  paid  tc  the 
generalised  requirements  system.  A  detailed  analysis  of  the 
collection  process  and  system  will  follow  in  the  remaining 
chapters  of  this  study.  Therefore  only  fundamental  consid¬ 
erations  of  that  process  as  it  relates  to  the  analytical  and 
requirements  systems  will  be  addressed  in  this  section.  The 
analytical  system,  though  critically  important  to  the 
overall  intelligence  process,  will  only  be  addressed  as  it 
relates  to  a  collection  system  -  the  primary  subject  of  the 
thesis.  The  dissemination  system  will  not  be  specifically 
addressed  due  to  its  relationship  and  identification  with 
the  type  of  communication  system  employed  by  the  intelli¬ 
gence  system.  The  ether  two  systems,  however,  are  more 
easily  isclated  from  the  specific  aspects  of  the  communica¬ 
tion  sytem  and  will  be  discussed. 

Figure  2.1  depicts  the  functional  relationships  formed 
between  the  three  major  components  of  a  tactical  intelli¬ 
gence  system.  Intelligence  requirements  are  generated  by 
the  users  of  the  system  -  subordinate  units,  staff  elements, 
and  the  commander.  These  requirements  can  be  satisfied  in 
one  of  three  ways  -  through  analysis,  collection,  or  a 
combination  of  the  two.  The  requirements  and  analysis 
systems  both  task  the  collection  system  for  intelligence 
information.  The  collection  system  primarily  responds  to 
such  tasking  and  rarely  would  task  the  other  two  systems  for 
substanitive  information. 

The  following  paragraphs  will  address  topics  related  to 
this  general  structure  and  its  functions  in  a  more  detailed 
manner. 


B.  BICOIBEHEHTS  SXSTIH 

A  requirements  system  must  be  able  to  accomplish  three 
basic  tasks: 


-  Receive  intelligence  requirements  from  users. 


-  Identify  the  nature  of  the  requirement  with  respect  to 
the  capabilities  of  the  particular  intelligence  system. 

-  Task  the  proper  functional  subsystem  (s)  of  the  intel¬ 
ligence  system  for  satisfaction  of  that  requirement. 

The  first  of  these  requirements  is  not  related  to  the  topic 
of  this  thesis.  The  other  two,  however,  are  more  inter¬ 
esting  and  and  will  be  addressed.  It  is  important,  pricr  to 
beginning  this  discussion,  to  first  understand  the  complex 
nature  of  an  intelligence  requirement. 

An  intelligence  requirement  is  a  representation  cf  a 
user's  need  for  information  concerning  the  disposition, 
capabilities  and  intentions  of  his  enemy.  Clearly,  this 
definition  is  quite  broad  and  necessarily  subjective  in 
nature.  .lore  specific  definitions  of  an  intelligence 
requirement  are  difficult  to  express.  Enumeration  of  all 
previously  identified  and  envisioned  requirements  is  imprac¬ 
tical  (and  probably  impossible).  It  is  possible,  however, 
to  classify  intelligence  requirements  into  functional 
categories.  This  classification  scheme  will  eventually 
allow  for  a  more  precise  representation  of  an  intelligence 
requirement. 

C.  TBE  CLASSIFICATICI  OF  I NTE1LIGENCE  REQUIREMESTS 
1.  Requirements  as  a  Function  of  Objective 

Every  intelligence  requirement  has  an  objective. 
For  the  most  part  that  objective  is  to  determina  or  clarify 
some  enemy  related  characteristic  which  at  the  present  time 
is  not  satisfactorily  defined.  The  requirement  objective 
may  be  related  to  enemy  capabilities.  This,  in  turn  is 
related  to  the  type  of  enemy  force  or  concern  -  armor, 
artillery,  chemical,  air  defense,  etc.  A  requirement  objec¬ 
tive  may  also  be  related  to  enemy  disposition.  In  this  case 
concern  would  be  directed  toward  the  spatial  orientation  of 


for 


ene  my  ur.its  on  the  battlefield.  Targeting  information, 
example,  foras  a  class  of  intelligence  re q uirements  whose 
objective  is  related  to  enemy  disposition.  Requirements 
related  to  first  or  second  echelon  forces  are  also  disposi¬ 
tion  oriented.  Other  requirement  objectives  are  related  to 
enemy  intentions.  These  requirements  are  generally  more 
subjective  in  nature  and,  hence,  their  eventual  satisfaction 
depends  upon  an  understanding  of  enemy  tactics  and  doctrine. 

The  point  to  be  made  is  that  an  objective  is  one 
factor  which  all  intelligence  requirements  have  in  common. 
Although  it  may  be  impossible  to  enumerate  all  possible 
requirement  objectives,  it  is  possible  to  relate  each 
requirement  objective  to  either  the  analysis  or  collection 
activities.  This  capability  is  important  and  will  allow  for 
a  greater  development  of  an  intelligence  collection  model  in 
this  thesis. 

2.  Requirements  as  a  Function  of  Time 

The  value  of  intelligence  information  is  often 
closely  related  to  time.  Some  types  of  information  are  of 
value  only  for  a  short  period  of  time.  Tactical  targeting 
data  is  an  example  of  such  information.  Other  types  of 
information  can  be  cf  value  for  greater  lengths  of  time. 
Information  concerning  the  communications  structure  of  the 
enemy  may  be  of  value  until  his  next  frequency  change. 
Thus,  an  intelligence  requirement  related  tc  some  ferm  of 
information  will  have  associated  with  it  some  temporal  rela¬ 
tionship  or  function.  Normally  this  relationship  identifies 
a  given  requirement  as  either  short  or  long  range  in  nature. 
This  temporal  relationship  is  critically  important  and  will 
be  discussed  throughout  this  study. 
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3.  gar tiall y  Satisfied  Requirements . 

Seme  require  iients  may,  after  a  first  effort  fcy  the 
intelligence  system,  be  only  partially  satisfied.  In  this 
situation  the  following  points  must  be  considered: 

a.  Extent  of  User  Satisfaction 

The  extent  of  the  user  satisfaction/ 
dissatisfaction  with  the  partially  satisfied  intelligence 
requirement  is  important  for  two  reasons.  The  most  impor¬ 
tant  is  that  of  determining  whether  or  not  the  requirement 
should  be  rctIaced  into  the  system.  If  the  level  of  dissat¬ 
isfaction  was  absolute  then  it  might  be  wise  to  consider 
resutmission.  However,  if  the  dissatisfaction  was  less 
severe,  then  resubmission  of  the  requirement  may  be  unwise. 
The  second  reason  this  consideration  is  important  deals  with 
improvement  of  the  requirements  system.  Any  system  must 
know  when  its  performance  is  unsatisfactory  if  it  is  to  have 
any  chance  of  lcng  range  success.  Information  concerning 
the  extent  of  user  satisfaction  therefore  is  useful  in  that 
it  provides  the  collection  system  operator  with  feedback 
concerning  the  performance  of  his  system. 

The  existence  of  partially  satisfied  require¬ 
ments  in  the  intelligence  system  suggests  that  some  proce¬ 
dure  for  reinsertion  cf  these  requirements  should  (if  that 
action  seems  suitable)  exist.  At  a  minimum  an  analyst 
should  be  aware  of  the  existence  of  such  requirements  and 
consider  their  impact  on  the  intelligence  process  and 
methods  cf  dealing  with  that  impact. 

t.  Requirement  Validity 

The  requirement  may  or  may  no  longer  be  valid. 
For  instance,  the  initial  informational  requirement  may  be 
such  that  delayed  or  subsequent  satisfaction  would  be  of 
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little  cr  nc  use  to  the  user.  In  this  situation  it  would 
not  be  wise  to  resubiiit  the  requirement  into  the  systeir  for 
satis  faction. 

c.  Partial  Requirement  Validity 

The  requirement  may  be  partially  satisfied  and 
therefore  only  partially  valid.  In  the  event  some  version 
of  the  original  demand  still  exists,  then  that  subset  of  the 
original  demand  (or  requirement)  might  be  replaced  into  the 
intelligence  system  fcr  further  action. 

4 .  Maintenance  Require ments 

Seme  requirements  are  generated  by  the  intelligence 
system  itself.  These  can  be  thought  of  as  overhead  costs 
which  must  be  expended  to  maintain  the  system.  These 
requirements  are  sometimes  referred  to  as  collection  or 
analytical  management  requirements. 

5*  Priority  of  Requirements 

Each  class  cf  requirements  may  also  be  defined  in 
terms  of  its  relative  importance  at  a  given  time  during  the 
tattle.  This  relative  requirement  importance  will  be 
referred  to  as  priority.  The  source  of  a  requirement's 
importance  could  be  any  number  of  things.  Some  of  these 
include  its  relationship  with  the  user  unit  or  organization, 
its  relationship  to  the  enemy,  or  perhaps  its  relationship 
to  a  certain  location  of  interest  on  the  battlefield.  The 
result  of  this  secondary  form  of  requirement  classification, 
from  a  modeling  point  of  view,  is  added  complexity.  This  is 
particularly  true  with  respect  to  determining  the  functional 
relationships  between  different  classes  of  intelligence 
requirements.  For  example,  is  a  long  range  requirement  of 
medium  priority  less  important  than  a  maintenance  require¬ 
ment  of  high  priority?  This  relationship  is  difficult  to 


describe  and  is  handled  best  when  broJcen  down  in  a  bit  acre 
detailed  manner. 

Ifae  previous  discussion  leads  to  the  following  func¬ 
tional  representation  of  an  intelligence  requirement.  It 
can  be  defined  in  terms  of  its  relationship  with  objective, 
time,  and  priority. 


Requirement  =  J (  objective,  time,  priority 


(eqn  2.1) 


Maintenance  requirements  are  treated  as  a  special  subset  of 
the  generalized  intelligence  reguirement  and  partially 
satisfied  requirements  are  treated  as  scaled  down  versions 
of  regular  intelligence  requirements. 

D.  fOHClICMS  OP  A  filCOIBEMENTS  SYSTEM 

Based  upon  this  brief  introduction  to  the  types  of 
requirements  which  are  associated  with  a  tactical  intelli¬ 
gence  system  it  is  new  possible  to  address  the  functions  a 
requirements  system  must  perform.  Figure  2.2  is  a  func¬ 
tional  schematic  of  a  generalized  requirements  system.  The 
discussion  which  follows  addresses  each  major  portion  of 
this  system. 

1.  Definition  and  Categorization  of  Requirements 

In  this  section  of  the  requirements  process  general 
intelligence  requirements  which  enter  the  system  frem  users 
are  mere  clearly  defined.  In  particular,  the  objective  of 
the  requirement  is  clearly  outlined.  Additionally,  the 
justification  for  the  intelligence  information  should  also 
be  determined  at  this  time.  From  this  clarification  process 
each  intelligence  reguirement  can  be  categorized  according 
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Figure  2.2  Requirements  Process. 


to  each  functional  parameter  mentioned  in  the  preceeding 
discussion.  These  are  addressed  below: 


a.  Requirement  Objective 

The  objective  of  the  requirement  shculd  be 
specifically  determined.  Not  only  should  the  najoi  objec¬ 
tive  classification  (disposition,  capaniiity,  or  intention) 
be  identified  but  also  any  identifiable  subclassi ficaticns 
which  might  provide  insight  into  the  nature  of  the  objec¬ 
tive.  Examples  of  such  sub classif ica tions  include  the  ulti¬ 
mate  use  cf  the  intelligence  information  (operations, 
terrain  analysis,  targeting),  the  types  of  enemy  forces  the 
user  is  most  interested  in,  etc.  The  ultimate  purpose  of 
this  section  is  to  provide  as  much  information  as  possible 
to  the  intelligence  system  concerning  the  nature  of  the 
requirement  objective. 


At  tms  point  in  the  process  the  purpose  in 
evaluating  the  time  parameters  of  the  requirement  is  simply 
to  determine  whether  or  not  any  special  handling  of  the 
requirement  is  necessary  due  to  its  possible  short  suspense 


time . 


c.  Priority 


The  requirement  priority  should  be  checked  for 
suitability.  Any  possible  definitional  priority  errors 
should  be  clarified.  For  instance,  it  may  be  that  for  a 
given  military  unit  the  standard  procedure  is  to  classify  a 
certain  type  of  intelligence  requirement  as  low  priority. 
This  process  should  be  able  to  detect  if  such  a  type 
requirement  were  submitted  at  an  improper  level  of  priority 
and,  subsequently,  properly  classify  the  requirement.  It 
should  be  noted  that  the  priority  a  user  requests  tc  be 
associated  with  his  requirement  may  not  correspond  to  that 
requirement’s  ultimate  priority  in  the  intelligence  system. 
The  ultimate  priority  is  determined  by  a  varity  of  factors 
(addressed  in  the  next  section)  which  the  user  may  or  may 
not  be  aware  of.  Kormally  the  priority  a  user  identifies 
with  his  requirement  serves  primarily  as  a  flag  in  the  event 
special  handling  is  required.  The  user’s  priority,  however, 
should  reflect  the  importance  he  places  on  that  requirement 
with  respect  to  his  ether  requirements. 

In  addition  to  the  above  it  should  also  be 
determined  whether  or  not  the  intelligence  system  can  actu¬ 
ally  respond  to  such  a  requirement  (some  requirements  are 
simply  impossible  to  satisfy)  .  This  determination  is 
referred  to  as  gross  suitability  and  will  be  addressed,  with 
respect  to  the  collection  system,  in  later  chapters. 
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Once  the  intelligence  requirement  has  :een  rede¬ 
fined  with  respect  to  the  parameters  discussed  atcve  it 
would,  under  normal  circumstances,  progress  througn  tae 
filtering  process  described  in  the  next  section.  If, 
however,  it  was  determined  from  this  defining  process  that 
immediate  or  special  processing  of  the  requirement  was 
called  for  then  it  should  be  possible  for  the  requirement  to 
bypass  the  filtering  process.  Thus,  in  some  cases  the 
inital  processing  of  the  intelligence  requirement  (defini¬ 
tion  and  categorization)  can  also  be  thought  of  as  a  coarse 
filtering  process. 

2.  Filter  (Prioritization  of  the  Requirement) 

A  filtering  process  must  basically  accomplish  two 
functions.  It  should  determine  if  the  requirement  can  be 
satisfied  with  information  already  on  hand  or  is  being 
worked  on  by  the  system  even  though  the  information  may  not 
actually  be  on  hand.  If  so,  then  the  normal  procedure  would 
seem  to  be  to  immediately  provide  the  user  with  the  appro¬ 
priate  information.  The  implications  of  this  seemingly 
simple  transaction  are  great.  It  implies  that  there  is  (or 
should  be)  an  effective  interface  (information  access) 
between  the  requirement  filtering  process  and  the  primary 
intelligence  data  base.  If  the  requirement  can  be  satisfied 
with  information  already  on  hand  then  it  would  seem  reason¬ 
able  to  forward  that  information  to  the  appropriate  users. 

It  should  also  determine  whether  or  not  a  require¬ 
ment  which  cannot  be  satisfied  with  on  hand  information  will 
be  satisfied  (and  at  what  level  of  effort)  through  tasking 
of  the  intelligence  system.  This  is  the  heart  of  the  prior¬ 
itization  process  and  as  such  can  become  quite  complex. 
Requirement  prioritization  is  basically  a  function  of  some 
cf  the  following  factors: 
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a. 


Command  Guidance 


Obviously  this  is  the  most  important  input  into 
the  filtering  process.  It  is  expected  (and  experience 
shows)  that  this  guidance  is  fairly  general  in  nature  and 
for  the  most  part  follows  the  dictates  of  current  plans  and 
operations.  More  specifically,  we  can  expect  the  commander 
to  be  concerned  that  friendly  units  involved  (or  soon  to  be 
involved)  in  combat  operations  receive  the  proper  amount  and 
guality  of  intelligence  support.  He  would  also  be  concerned 
that  all  significant  threats  to  the  well  being  of  his  unit 
are  identified  and  understood.  When  intelligence  resources 
are  scarce  the  commander's  guidance  also  serves  in  an  impor¬ 
tant  de  facto  resource  allocation  role. 

It  should  also  be  noted  that  as  any  combat  situ¬ 
ation  changes  the  nature  of  command  guidance  might  very  well 
change.  This  consideration  indicates  a  need  for  an  intelli¬ 
gence  system  to  be  flexible  enough  to  respond  to  any  tnvi- 
sioned  changes  in  command  guidance. 

b.  Criticality  of  the  Seguireaent 

Certain  types  of  intelligence  will  almost  always 
be  of  greater  importance  to  the  unit  than  others.  Normally, 
these  types  of  information  are  of  potentially  great  threat 
to  the  unit  or  of  extreme  importance  to  the  outcome  of  the 
unit's  mission.  An  example  of  high  threat  information  might 
be  that  related  to  the  enemy's  current  capability  to  deliver 
nuclear  weapons.  Information  of  high  importance  might  be 
that  related  to  the  enemy's  command  and  control  structure. 
It  should  be  noted  that  the  potential  importance  cf  a 
requirement  could  easily  be  described  as  a  dynamic  process 
with  respect  to  the  conduct  of  the  battle.  For  example, 
intelligence  concerning  a  nuclear  capable  missile  with  a 
range  of  100  kilometers  becomes  more  and  more  important  as 
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that  missile  moves  from  rear  areas  to  forward  positions  or. 
the  hattlefield. 

c.  Answerability  of  the  Requirement 

Some  requirements  simply  cannot  be  addressed  by 
the  system.  A  time  sensitive  (i.e.  the  information  is 
needed  quickly)  yet  legitimate  requirement  (legitimate  in 
the  sense  that  the  system  under  normal  circumstance  would 
and  cculd  respond  to  such  a  requirement)  may  be  unanswerable 
due  to  the  limitations  of  the  intelligence  system  itself. 
Similarly,  an  overly  detailed  requirement  may  also  be  beyond 
the  capabilities  of  the  system.  The  following  intelligence 
system  responses  to  this  type  of  requirement  can  be 
envisioned. 

-  Reject  the  requirement  outright. 

-  Pass  the  requirement  forward  to  higher  or  lower  units 
for  possible  satisfaction. 


-  Negotiate  the  specifics  of  the  requirement  with  the 
user  to  determine  if  one  or  more  of  the  restraints  can 
be  relaxed. 


d.  Quantity  of  Users 

The  stresses  on  the  system,  both  from  a  manage¬ 
ment  and  resource  allocation  point  of  view,  increase  with 
the  presence  of  more  users  in  the  system.  It  is  expected 
that  these  demand  related  stresses  would  be  clearly 
reflected  in  the  filtering  process.  In  particular  one  would 
expect  that  requirements  not  fitting  into  a  certain  meld  of 
acceptability  would  have  less  chance  of  passing  unhindered 
through  the  filter  during  periods  of  heavy  demand  rather 
than  light  demand.  Thus,  it  becomes  clear  why  the  initial 
definition  of  the  requirement  process  is  very  important.  It 
helps  to  insure  that  a  user  generated  requirement  is 
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described  in  terns  the  requirement  filtering  process  can 
understand. 

e.  Time 

This  is  cne  of  the  most  important  and  ccirpli- 
cated  cf  all  priority  parameters.  The  following  paragraphs 
describe  some  of  the  time  related  concepts  which  relate  to 
the  filtering  process  of  the  requirements  system. 

Many  organizations  in  a  given  unit  have  similar 
intelligence  needs.  As  a  result,  often  identical  (or  nearly 
so)  intelligence  requirements  are  placed  into  the  intelli¬ 
gence  system.  To  limit  the  waste  associated  with  this  type 
cf  problem  the  intelligence  system  periodically  prepares 
reports  cf  common  interest.  Numerous  (primarily  routine) 
intelligence  requirements  can  be  satisfied  through  the 
publication  of  timely  periodic  intelligence  reports.  The 
publication  of  such  reports  should  thus  ha  we  some  effect  on 
the  requirements  filtering  process.  Specifically,  the 
timing  of  these  reports  will  be  of  some  importance.  For 
instance,  requirements  submitted  into  the  system  which  one 
can  expect  will  be  reasonably  well  satisfied  (from  a  timeli¬ 
ness  and  guality  of  information  point  of  view)  with  a  scon 
to  be  published  periodic  report  should  probably  be  rejected 
with  the  caveat  that  the  information  will  soon  be  forth¬ 
coming.  Of  course,  measures  must  be  taken  to  insure  that 
the  requested  i  if ormation  does  eventually  get  to  the  user 
whose  requirement  was  initially  rejected. 

An  additional  aspect  for  consideration  with 
respect  to  the  publication  of  such  reports  is  that  of 
resource  alloction.  The  publication  of  periodic  reports 
places  a  drain  on  the  capability  of  the  intelligence  system 
similar  to  the  type  cf  drain  placed  on  it  by  excessive  quan¬ 
tities  cf  users.  Thus,  there  is  a  cost  associated  with  the 
production  cf  such  reports.  This  cost  should  be  defined  and 
reflected  in  the  filtering  process. 


One  can  look  at  the  publication  or  periodic 
reports  as  an  action  which  decreases  the  requirement  load  on 
the  intelligence  system  (by  making  the  filtering  process 
more  stringent)  while  the  resources  allocated  in  preparation 
of  the  intelligence  reports  can  be  looked  upon  as  an  action 
which  increases  the  stress  on  the  intelligence  system  (by 
reducing  the  resources  available  for  the  satisfaction  of 
requirements).  A  gccd  balance  between  value  and  cost  mcst 
exist  if  periodic  reports  are  to  be  useful  to  the  intelli¬ 
gence  system. 

On  occasion,  requirements  can  conflict  with 
ongoing  collection  operations.  This  is  similar  to  the 
consideraticn  addressed  above.  During  certain  types  of 
intelligence  operations  one  can  expect  that  nearly  all  (or 
some  significant  portion)  of  available  intelligence 
resources  might  be  employed.  At  these  times  it  is  possible 
that  many  valid  intelligence  requirements  which  might 
disrupt  an  ongoing  intelligence  operation  may  not  be  satis¬ 
fied.  The  point  to  he  made  is  that  the  failure  to  address 
the  valid  requirement  is  not  necessarily  due  to  the  overall 
lack  cf  resources  available  but  rather  the  fact  that  the 
specific  requirement,  from  a  temporal  point  of  view,  has 
come  into  conflict  with  an  ongoing  (resource  draining) 
intelligence  operation.  At  any  other  point  in  time  it  is 
conceivable  that  the  same  requirement  may  have  been  satis¬ 
fied.  Therefore,  tie  timing  cf  intelligence  operations  (in 
particular  the  scheduling  of  such  operations)  is  possibly  an 
important  input  parameter  to  the  requirements  filtering 
process.  This  difficulty  can  be  limited  by  interfacing  with 
the  appropriate  users  to  determine  if  delays  in  satisfaction 
of  the  requirement  might  be  somewhat  acceptable. 

There  exist  time  delays  associated  with  the 
production  of  certain  forms  of  intelligence.  These  time 
delays,  when  contrasted  with  the  time  constraints  cf  a 
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particular  intelligence  requirement  itself,  may  net  allow 
for  the  satisfaction  of  the  requirement.  Such  delays  may 
come  in  the  form  of  a  lead-time  delay  (applicable  in  certain 
scheduled  types  cf  operations  cr  in  operations  which  require 
a  certain  amount  of  warm-up  time  prior  to  producing  intelli¬ 
gence),  and  lag-time  delays  (applicable  in  the  situation  in 
which  the  requirement  time  restraint  is  shorter  than  the 
resource  time  restraint  -  thus  information  produced  to 
satisfj  the  given  requirement  will  be  late  (and  probably 
less  that  optimal)  . 

The  filtering  process  must  therefore  be  able  to 
compare  two  classes  cf  time  restraints  -  those  associated 
with  the  user's  actual  intelligence  requirement  and  those 
associated  with  the  intelligence  system.  Figure  2.3 
outlines  this  time  analysis  process. 


Figure  2.3  Time  Analysis 


3.  Cct ail ed  Requirements  Analysis 

After  passing  through  the  filtering  process  a 
reguirement  is  considered  to  he  valid  -  somethin  g  which  the 
intelligence  system  must  react  to  (and  hopefully  satisfy) . 
However,  the  functional  structure  of  the  intelligence  system 
(requirements,  analysis,  collection)  is  fairly  strict. 
Thus,  the  requirement  must  be  further  translated  into  func¬ 
tional  terms  which  the  system  can  act  upon.  The  first  step 
in  this  process  is  determining  the  dimensionality  of  the 
requirement.  The  dimensionality  of  a  given  intelligence 
requirement  refers  tc  whether  or  not  that  requirement  can  be 
satisfied  using  analytical  intelligence  resources,  collec¬ 
tion  intelligence  resources,  or  a  combination  of  the  two 
types  of  resources.  Thus,  a  requirement  can  be  thought  of 
as  being  single  dimensioned  (either  an  analytical  or  collec¬ 
tion  requirement)  or  multi-dimensioned  (an  analytical  and 
collection  requirement).  Figure  2.5  (Detailed  Requirements 
Analysis)  illustrates  the  dimensioning  possibilities  related 
to  any  given  intelligence  requirement. 

Determination  of  the  dimensionality  of  a  given 
requirement  may  be  a  fairly  complicated  process.  This  is 
particularly  true  with  respect  to  multi-dimensioned  require¬ 
ments.  Such  issues  as  resource  availability  and  time  become 
important  factors  which  can  create  variability  in  the  dimen¬ 
sionality  of  a  reguirement.  For  instance,  given  a  rather 
vague  requirement  such  as: 

-  Khere  will  the  enemy  2nd  echelon  be  deployed? 

Cne  can  envision  the  difficulty  of  determining  which  aspects 
cf  the  requirement  are  analytical  in  nature  and  which  are 
more  collection  oriented  in  nature. 

It  should  be  noted  that  once  the  dimensionality  of  a 
given  requirement  has  teen  determined,  it  is  not  necessarily 


Figure  2.5  Detailed  Beguirements  Analysis. 

static.  Specifically,  the  changing  availability  of  analyt¬ 
ical  and  collection  resources  affects  the  dimensionality  of 
any  giver  requirement.  This  fact  suggests  that  some  sort  of 
interface  should  exist  between  the  operational  structures  of 
the  intelligence  system  with  respect  to  valid  intelligence 
reguirements. 

Cnee  the  dimensionality  of  a  given  intelligence 
requirement  has  been  determined,  it  will  be  passed  tc  the 
appropriate  systems  (analytical  and/or  collection) .  Each 
system  will  then  continue  to  redefine  the  requirement  into 
terms  *hich  relate  tc  their  own  functions. 

At  this  point  in  the  process  the  requirements  system 
has  completed  its  function  of  receiving  the  requirement. 
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deter iciriing  whether  cr  not  that  requirement  will  be  acted 
upon  by  the  intelligence  system#  and  forwarding  a  more  func¬ 
tionally  oriented  requirement  to  either  the  analytical 
system,  collection  system,  cr  both. 

I.  AMAI1U  CAL  SYSTEM 

1 .  Objective  and  Structure  of  th e  Analytical  System 

Ihe  objective  of  a n  analytical  system  is  to  piece 
together  data  from  a  variety  of  sources  (to  include  judge¬ 
mental)  to  provide  the  user  with  intelligence  information  of 
value.  Given  the  intelligence  system  structure  depicted  in 
Figure  2.1  and  the  previous  discussion  concerning  the  intel¬ 
ligence  requirements  system,  an  analytical  system  might 
appear  as  that  shown  in  Figure  2.  6.  Several  features  of 
this  structure  are  noteworthy. 


Figure  2.6  Analytical  System. 
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a.  Tasking  cf  the  Analytical  System 


The  analysis  system  is  tasked  (within  the  intel- 
lignce  systems  structure)  by  the  requirements  system.  This 
relationship  implies  that  the  analysis  system  must  receive 
incoming  valid  requirements  (described  functionally  as 
outlined  in  the  previous  section)  and  provide  some  level  of 
feedback  regarding  the  status  of  that  requirement.  The 
analysis  system  must  also  be  able  to  task  the  collection 
system  in  order  to  help  satisfy  its  informational 
shortfalls. 

b.  Non-organic  Analytical  Resources 

A  relationship  exists  between  an  analytical 
system  and  other  non-organic  analytical  resources.  Such 
resources  might  include  analytical  activities  of  subordi¬ 
nate,  superior,  or  supporting  units  and  organizations.  This 
relationship  could  be  defined  in  terms  of  authority  (i.e. 
one  organization  would  have  tasking  authority  over  another) 
or  in  terms  of  a  liasion  type  function  (which  suggests  orly 
cooperative  actions  between  the  designated  activities) . 

These  two  characteristics  imply  that  the  capa¬ 
bilities  cf  an  analytical  system  are  not  necessarily  static 
and  may  change  in  structure  during  the  course  of  a  given 
combat  operation.  for  instance,  access  to  non-organic 
analytical  assets  may  be  limited  if  the  unit  is  serving  in  a 
reserve  capacity.  Access  would  probably  increase,  however, 
in  the  event  that  the  same  unit  were  to  be  placed  in  direct 
contact  with  enemy  forces. 

Additional  features  of  the  analytical  system 
make  it  difficult  to  describe.  The  nature  of  the  analytical 
process  is  often  subjective.  This  is  primarily  the  result 
of  the  types  of  information  the  system  is  provided  with  and 
the  types  of  information  the  system  is  asked  to  produce. 


2 .  lime  Considerations  of  the  Analytical  System 


a. 
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t.  Analysis  Sith  Conflicting  Information 


Analysis  often  occurs  under  conditions  of 
conflicting  information.  Information  pertaining  to  an 
intelligence  requirement  will  sometimes  be  of  a  contradic¬ 
tory  nature.  In  this  situation  the  analysis  activity  must 
be  able  to  evaluate  which  information  is  best  suited  for 
inclusion  in  the  analytical  process.  This  evaluation  can  be 
complicated  and  time  consuming  in  that  questionable  informa¬ 
tion  cf  potential  importance  may  be  of  such  a  complicated 
form  that  it  must  first  be  re-evaluated  by  the  collecting 
activity.  Subsequent  time-lag  complications  often  hinder 


the  inferma 

tion 

evaluation  process 

even 

f  urt 

her . 

The  ret 

result  of 

these 

complications  is 

that 

the 

decision 

as  to 

which  set 

cf  in 

formation  is  more 

accurate 

becomes 

judge- 

mental  and 

often 

less  them  objective  in 

nature. 

c.  Time  and  Spatial  Projection  of  Analyses 


Intelligence  analysis  must  be  predictive  in 
nature.  Thus,  the  analysis  activity  must  be  able  to  (based 
cn  past  information  for  the  most  part)  project  their  anal¬ 
yses  into  the  future  to  answer  such  questions  as: 


When  will  the  enemy  be  prepared  to  attack? 


-  When  will  the  2nd  echelon  arrive  at  the  FLOT  (Front 
Line  cf  Troops)? 

Additionally,  the  analysis  activity  mist  be  able  to  project 
from  a  spatial  point  cf  view.  For  instance,  analysis  must 
address  questions  of  the  form: 

-  Where  will  the  enemy  be  located  in  6  hours? 

Some  of  these  predictive  evaluations  may  be 
suited  to  mathematical  models.  Specifically,  movement 
models  and  enemy  arrival  rate  models  may  have  a  certain 
level  cf  applicability.  However,  the  information  upon  which 
models  must  depend  may  or  may  not  be  at  a  level  of  accuracy 
or  precision  which  is  required  for  satisfactory  model 
performance . 

For  the  resaons  mentioned  in  the  previous 
discussion  it  should  be  clear  that  modeling  an  analysis 
system  would  be  a  difficult  task  due  to  its  subjective  func¬ 
tional  nature.  Fortunately,  this  study  is  only  concerned 
with  the  relationship  between  the  collection  system  (the 
primary  subject  of  this  study)  and  the  ana4jftical  system. 
Specifically,  an  analytical  system  tasks  a  collection  system 
to  help  satisfy  intelligence  requirements. 


III.  A  COLLECTION  SYSTEM  OVER  VIES 

A.  OBJECTIVE  OF  A  CCIIECTICN  SYSTEM 

The  objective  of  a  collection  system  is  to  satisfy,  in 
the  context  of  the  battlefield  situation,  informational 
shortfalls  resulting  from  intelligence  requirements  being 
placed  upon  the  intelligence  system.  A  collection  system 
accomplishes  its  objectives  through  the  employment  of  a  wide 
variety  cf  sensors  (both  human  and  technical)  which  have  the 
capability  of  detecting  different  forms  of  enemy  activity. 
The  employment  of  these  sensors,  however,  is  not  necessarily 
direct.  For  the  remainder  of  this  study  intelligence 
collection  sensors  will  be  referred  to  as  collection  plat¬ 
forms.  Collection  platforms  can  be  highly  specialized 
(discussed  in  more  detail  later)  .  The  operation  of  such 
platforms,  accordingly,  is  often  complicated  and  requires 
substantial  personnel  and^  support  resources.  These 

resources,  to  include  their  related  collection  platform(s), 
will  te  referred  to  as  a  collection  subsystem.  A  collection 
system  is  composed  of  one  or  more  collection  subsystems 
(normally  mere)  .  Thus,  a  collection  system  acquires  needed 
intelligence  information  through  the  management  of  ere  or 
more  collection  subsystems. 

E.  STBOCTORE  OF  A  CCIIECTICN  SYSTEM 

1 .  Collection  Platform s 

Collection  platforms  are  sensors,  both  human  and 
technical,  which  possess  seme  capability  of  detecting 
certain  forms  of  enemy  activity  or  presence.  Operationally 
deployed  platforms  are  numerous  in  quantity  and  vary  greatly 
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in  th€ir  functional  medium  and  operational  capabilities.  It 
is  easy  to  distinguish  and  separately  classify  human  plat¬ 
forms  from  technical  platforms.  Different  types  of  tech¬ 
nical  platforms  are  more  difficult  to  classify.  Normally 
they  are  categorized  into  groups  according  to  the  manner  in 
which  intelligence  information  is  collected.  For  instance, 
those  which  collect  signal  related  intelligence  information 
are  grouped  into  a  functional  category  referred  to  as  SIGINT 
(standing  for  signal  intelligence)  platforms.  Similarly, 
those  technical  platforms  which  employ  images  in  the  collec¬ 
tion  process  are  grouped  into  a  functional  category  referred 
to  as  IMINT  (standing  for  imagery  intelligence)  platforms. 
For  cbvicus  reasons,  human  intelligence  sensors  are  referred 
to  functionally  as  HOBINT  platforms. 

As  previously  mentioned,  collection  platforms  are 
useful  because  they  possess  a  valuable  operational  capa¬ 
bility.  This  capability  can  be  defined  as  a  function  of  the 
following  parameters: 

a.  Function^.  Medium  (Mf) 

For  human  platforms  the  medium  is  cbvious. 
Technical  platforms  tend  to  operate  (collect  information)  at 
some  location  (or  within  some  range)  of  the  electromagnetic 
spectrum.  For  instance,  communications  intercept  platforms 
normally  collect  information  over  some  range  of  freguencies 
(and  transmission  modes)  -  HF,  microwave,  etc.  Similarly, 
photographic  platforms  collect  over  some  range  of  light 
freguencies  -  IE,  visual,  etc. 

k.  Functional  Capability  (C^) 

Given  the  medium  in  which  a  platform  operates  it 
must  also  possess  sene  limits  to  its  sensing  capabilities. 
Those  limits  might  be  resolution  levels,  sensitivity  levels, 
maxiiua/minimum  range  capabilities,  etc. 


c.  Physical  Sedium  (M-.) 

For  the  Air/Land  battle  we  are  obviously 
concerned  whether  the  platform  operates  on  the  ground,  in 
the  air,  or  both. 

d.  Physical  Capability  (C-0 

This  parameter  refers  to  the  limits  on  the  phys¬ 
ical  capabilities  of  the  platform.  These  limits  would 
perhaps  would  identify  the  platform  as  having  a  night  or 
all-weather  capbility  vs.  a  strictly  daylight  capability. 

e.  Time  (T ) 


Time  is  an  extremely  important  parameter. 
Although  a  strong  argument  could  be  made  that  time  is 
related  to  either  the  functional  or  physical  capability  of  a 
given  platfcrm,  it  is  identified  spearately  because  of  its 
critical  importance.  There  are  several  reasons  the  time 
parameter  receives  such  distinction.  First,  a  given  collec¬ 
tion  platfcrm  may  need  a  certain  amount  of  time  to  perform 
its  collection  function.  For  instance,  a  aerial  surveil¬ 
lance  radar  may  reguire  a  particular  amount  of  emmission 
time  in  crder  to  collect  an  image  of  its  area  of  concern  on 
the  battlefield.  Second,  time  may  be  required  to  satisfy 
the  physical  limitations  of  the  platform.  In  particular,  an 
aerial  platform  may  have  to  fly  from  a  distant  airfield  to 
its  collection  point  {and  return)  -  thus  consuming  time. 
Numerous  additional  time  related  factors  could  potentially 
affect  tfce  operation  of  a  given  collection  platform  (atmos¬ 
pheric  conditions  at  night  in  Europe  tend  to  disrupt  certain 
forms  of  HF  communications  systems)  and  thus  time  is 
presented  as  a  separate  parameter  defining  the  operational 
capability  of  a  collection  platform. 


The  operational  capanlity  (O.C.)  of  a  collec¬ 
tion  platform  can  he  represented  by  the  following 
relationship: 
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(eqn  3.1) 


2.  Collect  ion  Subsystems 

A  collection  subsystem  consists  of  those  resources, 
both  human  and  technical,  which  directly  control  the  opera¬ 
tional  employment  of  a  collection  platform.  One  or  more 
collection  platforms  may  be  under  the  control  of  a  collec¬ 
tion  subsystem  at  any  given  time  during  an  operation. 
Collection  platforms,  when  under  the  control  of  a  collection 
subsytem,  are  considered  part  of  the  collection  subsystem. 

Collection  subsystems  normally  control  platforms 
which  are  functionally  related  to  one  another.  For 
instance,  a  signal  intelligence  collection  subsystem  would 
normally  ccntrol  collection  platforms  which  are  capable  of 
detecting  and  perhaps  analyzing  enemy  communications  and 
non-ccmmunications  emitters.  Likewise,  an  imagery  intelli¬ 
gence  collection  subsystem  would  normally  consist  of  all 
collection  platforms  which,  in  the  process  of  collecting 
information  on  the  enemy,  produce  images  for  analysis.  On 
occasion,  collection  subsystems  are  organized  along  less 
functional  lines.  Fcr  instance,  there  exist  both  Army  and 
Air  Force  collection  platforms  which  produce  radar  images  of 
potential  battlefields.  Although  the  platforms  are  func¬ 
tionally  similar  they  are  not  normally  found  under  the 
contrcl  of  a  single  collection  subsystem.  Each  service 
tends  tc  control  its  own  platforms.  Thus,  in  this 


situation,  functionally  similar  collection  platforms  are 
controlled  by  separate  service  related  collection 
subsystems. 

It  seems  reasonable  to  suggest  that  the  operational 
capability  of  a  given  collection  subsystem  might  be 
expressed  as  the  sum  cf  the  operational  capabilities  of  its 
collection  platforms.  This  relationship  might  be  valid  if 
it  could  be  shown  that  tne  parameters  of  each  platform  were 
independent  of  one  another.  Unfortunately,  this  is  net  true 
in  all  cases. 

a.  Functional  Medium 

In  the  event  the  collection  platforms  operate  in 
entirely  different  portions  of  the  electromagnetic  spectrum 
then  one  could  reasonable  argue  for  independence  with 
respect  to  this  parameter  and  a  simple  subsystem  parameter 
could  be  formulated.  Otherwise,  some  relationship  between 
platforms  would  exist  and  the  formulation  of  a  subsystem 
parameter  wculd  be  mere  difficult. 

b.  Functional  Capability 

In  the  event  that  the  functional  medium  of  the 
platforms  cf  concern  were  determined  to  be  independent  then 
it  is  likely  that  their  functional  capability  parameters 
would  also  be  independent  of  one  another.  If  their  respec¬ 
tive  Mcs  were  dependent,  however,  then  there  would  be  a 
possibility  that  they  would  also  be  dependent  with  respect 
to  the  capability  parameter. 

c.  Physical  Medium 

In  the  event  that  two  or  more  collection  plat¬ 
forms  reguired  an  identical  portion  of  a  physical  medium  in 
which  to  operate  then  a  dependent  relationship  with  respect 
to  this  parameter  wculd  exist.  At  first  glance,  the 
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possibility  of  the  cccurance  of  tais  problem  might 
remote.  Consider,  however,  the  availability  of  coimnica- 
tions  advantageous  terrain  on  a  potential  battlefield.  The 
availability  of  such  terrain  can  and  often  is  quite  limited 
and  thus  the  possibility  that  two  or  more  platforms  would 
compete  for  the  use  of  such  terrain  appears  more  likely. 
Thus,  if  two  or  more  platforms  have  a  common  physical  medium 
the  possibility  exists  for  a  dependent  relationship  and  a 
subsystem  representation  of  this  relationship  would  have  to 
he  developed. 

d.  Physical  Capability 

If  the  physical  mediums  of  collection  platforms 
are  dependent  upon  cue  another  then  the  possibility  exists 
that  the  capability  parameter  of  those  systems  are  also 
dependent.  This  situation  is  similar  to  that  between  func¬ 
tional  medium  and  functional  capability  described  in 
Paragraph  (b)  above. 

e.  Time 

It  is  likely  that  the  time  parameter  of  an  indi¬ 
vidual  platform  is  related  to  that  of  another  if  any  of 
their  ether  parameters  are  related.  Thus,  the  probability 
of  a  relationship  between  the  time  parameters  of  two  or  more 
collection  platforms  is  greater  than  that  of  any  ether 
single  parameter. 

A  simple  algorithm  which  could  help  determine 
the  existance  of  paramter  dependencies  among  the  collection 
platfcrms  of  a  collection  subsystem  is  outlined  at  Figure 

3-1. 

It  is  clear  that  dependencies  between  opera¬ 
tional  parameters  of  a  given  set  of  collection  platforms 
could  be  identified.  The  interpretation  of  such  dependen¬ 
cies  is,  however,  more  difficult  if  not  impossible  to 


Figure  3.1  Dependency  Analysis. 

determine.  Thus,  the  suggestion  to  repc esent  the 
operational  capability  of  a  given  collection  subsystem  as  a 
simple  sum  of  the  operational  capabilities  of  its  collection 
platforms  is  not  justified  except  in  cases  where  no  depen¬ 
dencies  exist. 

Further  investigations  in  determining  these 
sorts  of  relationships  would  certainly  be  appropriate.  For 
the  purposes  of  this  project,  it  will  be  assumed  that  a 
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composite  relationship  representing  the  operational 
parameters  of  a  group  of  collection  platfocms  can  be 
formulated.  From  this  composite  relationship  a  representa¬ 
tion  of  the  operational  capability  of  a  given  collection 
subsystem  could  be  formulated. 

Recall  that  collection  subsystems  often  consist 
of  collection  platforms  with  similar  functional  capabili¬ 
ties.  For  this  reason  one  could  think  of  a  given  collection 
subsystem  as  an  entity  which  would  be  associated  with 
collecting  a  certain  class  or  category  of  intelligence 
information.  The  categories  of  information  which  a 
subsystem  would  be  able  to  collect  would,  of  course,  be 
quite  closely  related  to  the  operational  capabilities  of  the 
subsystem.  The  operational  capability  of  a  given  subsystem, 
in  turn,  would  be  defined  by  the  relationship  between  plat¬ 
form  capabilities  (discussed  above)  and  any  efficiency  or 
inefficiency  multipliers  associated  with  the  management  of  a 
collection  subsystem. 


C.  COLLECTION  SISTEB 

A  collection  system  consists  of  one  or  more  collection 
subsystems  and  all  the  resources  necessary  for  its  (their) 
control.  A  collection  system  consisting  of  nine  collection 
platforms  and  three  collection  subsystems  could  be  struc¬ 
tured  in  a  variety  of  manners.  Two  possible  structures  are 
depicted  on  Figure  3.2. 

The  exact  structure  of  a  given  collection  system  is 
determined  by  the  quantity  and  type  of  subsystems  and  plat¬ 
forms  under  its  control.  During  an  operation  the  number  of 
subsystems  under  a  unit's  control  will  change  as  a  function 
of  battlefield  relationships.  Thus,  the  structure  of  a 
collection  system  is  itself,  a  variable.  This  is  an 
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Figure  3.2  Collection  Systems  Structures. 

important  concept.  The  implication  being  that  as  the  course 
of  the  tattle  changes,  the  structure  (and  hence  capability) 
of  the  intelligence  collection  system  will  also  change. 

The  next  portion  of  the  study  will  address  the  functions 
of  the  various  components  of  the  collection  system 
structure. 


A  »*• 
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D.  FONCTICNS  OF  A  CCILECTICN  SYSTEM 

1.  Collection  Plat  for  as 

The  collection  platform  is  the  fundamental  unit  and 
scarce  resource  of  the  collection  system.  The  entire 
collection  system  and  subsystems  were  developed  to  effec¬ 
tively  control  the  collection  platform.  As  objects  of 
control  collection  platforms  receive  inputs  from  their 
controlling  source,  respond  to  these  inputs  by  interfacing 
in  seme  form  or  another  with  measureable  indications  of 
enemy  activity,  and  return  (to  the  controller)  operational 
data  related  to  that  interfacing  activity.  In  order  to 
successfully  accomplish  these  functions  a  given  collection 
platform  must  be  able  to  communicate  (input  and  output)  with 
its  controllers.  A  diagram  of  the  functions  a  collection 
platform  must  perform  is  shewn  at  Figure  3.3.  Many  varia¬ 
tions  of  this  functional  model  are  possible.  One  common 
variation  occurs  when  the  collection  platform  sends  raw 
operational  data  to  activities  other  than  the  controllers. 
Otherwise,  the  model  shown  at  Figure  3.3  is  general  enough 
to  cover  many  of  the  platforms  currently  in  use  by  the  Army. 

2.  Collection  Subsystems 

Collection  subsystems  control  the  operation  of  one 
or  more  collection  platforms.  As  a  controlling  source  they 
must  provide  control  input  which  is  understandable  to  each 
platform  within  the  subsystem.  From  each  platfcrm  the 
collection  subsystem  receives  intelligence  data. 

Collection  subsystems  are  also  controlled  by  collec¬ 
tion  systems.  As  a  controlled  system  it  must  receive 
control  inputs  from  its  controlling  source  and  provide 
intelligence  data  (perhaps  translated)  to  the  controlling 
source.  The  control  inputs  from  the  collection  system  to 
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Figure  3.3  Collection  Platform  Functions. 

the  subsystem  will  not  be  identical  to  those  from  the 
subsystem  to  the  platform.  They  (subsystem  to  platform 
inputs)  will  for  the  most  part,  however,  reflect  the  inten¬ 
tions  of  the  system  to  subsystem  inputs.  Likewise,  the 
intelligence  data  received  from  the  platform  may  not  be 
identical  to  that  forwarded  from  the  collection  subsystem  to 
the  collection  system. 

Technical  and  specialized  platforms  require  precise 
control  inputs  and  return  precise  data  -  neither  of  which  is 
normally  comprehensible  to  the  untrained  user.  Thus  the 
requirement  for  the  subsystem  to  serve  as  a  translator.  As 
the  number  of  collection  platforms  increase  in  a  given 
collection  subsystem  cne  can  easily  see  how  the  functional 
complexity  cf  the  subsystem  increases.  This  is  particularly 
true  in  the  case  of  widely  varying  types  of  collection  plat¬ 
forms.  Figure  3.4  depicts  the  functions  of  a  collection 


Figure  3.4  Collection  Subsystem  Functions. 

3 -  Collection  Systems 

Collection  systems  control  the  operations  of  one  or 
more  collection  subsystems.  To  accomplish  this  task  the 
collection  system  forwards  controlling  inputs  to  appropriate 
subsystems  and  receives  intelligence  data  from  them  (or  on 
occasion  directly  frcm  a  collection  platform) .  The  collec¬ 
tion  system  is  also  controlled  (as  previously  mentioned)  by 
ether  elements  within  the  intelligence  system  (analytical 
and  collection  systems)  .  A  collection  system  is  function¬ 
ally  similar  to  the  general  collection  subsystem  shown  in 
Figure  3.4.  In  this  case,  however,  the  controlling  sources 
are  elements  of  the  intelligence  system  and  the  platforms 
are  ccllection  subsystems.  Figure  3.5  depicts  the 
functional  nature  of  a  collection  system. 
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Changing  battlefield  conditions  often  dictate 
changes  in  military  organizational  structures.  As  alluded 
to  in  previous  discussion,  collection  systems  experience 
such  battlefield  structural  changes.  These  changes  are 
often  more  abrupt  (occur  without  warning)  than  these  found 
in  more  typical  military  units.  This  is  the  result  of  the 
multiservice/multicommand  make-up  of  collection  platforms 
and  subsystems.  This  dynamic  structure  adds  complexity  to 
both  the  nanagement  of  the  collection  effort  and  the 
resulting  data  flow. 


3.  Time  and  Spatial  Project  ion  of  Intelligence 

Collection 

The  intelligence  collection  system,  for  the  most 
part,  responds  to  the  needs  of  the  the  Requirement  and 
Analytical  Systems  cf  the  Generalized  Intelligence  System. 
These  needs  invariably  are  more  concerned  about  the  future 
nature  of  the  enemy  on  the  battlefield  rather  than  their 
current  status.  As  a  result,  the  collection  effort  must 
also  be  focused  on  the  future.  This  orientation  adds 
complexity  in  planning  and  implementing  intelligence  collec¬ 
tion  operations.  lead/lag  time  considerations  for  both 
platfcrm  performance  and  the  many  levels  of  planning 
required  is  a  difficult  problem  in  itself.  Much  effort  is 
currently  aimed  at  sclving  scheduling  problems  arising  from 
lead/lag  time  considerations.  Added  to  these  time  difficul¬ 
ties  is  the  spatially  dynamic  nature  of  the  battlefield. 
The  location  of  the  enemy  forces  of  concern  at  unknown 
future  times  is  difficult  to  determine.  Thus  the  future 
orientation  of  the  intelligence  system  tends  to  create  plan¬ 
ning  and  implementation  difficulties  for  the  collection 
systex. 
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4  •  Multiple  Use rs  with  Different  and  Changing  Levels  of 

Access 

Numerous  users  are  allowed  access  to  the  resources 
of  a  collection  system.  The  mere  variety  associated  with 
such  numbers  imples  that  a  collections  systems’s  capabili¬ 
ties  (with  respect  to  toth  the  collection  effort  and  trans¬ 
mission  of  information)  must  he  broad.  Increased  quantities 
of  users  leads  to  obvious  difficulties  in  managing  any 
complex  system.  Users  of  a  collection  system  are,  with  the 
aid  of  a  priority  system,  allowed  varying  degrees  of  access. 
A  high  priority  unit  would  normally  be  allowed  greater 
access  than  a  lew  priority  unit.  The  priority  of  access 
often  changes  during  the  course  of  an  operation  as  units  are 
shifted  about  the  battlefield.  The  collection  system  should 
be  able  to  cope  with  such  changes. 

These  and  other  considerations  suggest  that  a 
description  of  the  structure  and  functions  of  a  collection 
system  might  be  somewhat  complicated.  The  collection  system 
is  not  the  master  of  its  own  destiny.  The  number  of  users 
(and  their  level  of  access)  as  well  as  the  number  of 
resources  needed  to  satisfy  those  users  both  vary  as  a 
function  of  current  battlefield  conditions. 


IV.  COLLECTION  REQPIBEMENTS 


The  control  parameters  of  collection  systems,  subsys¬ 
tems,  and  platforms  are  intelligence  collection  requirements 
cr  translated  portions  of  intelligence  collection  require¬ 
ments.  To  understand  the  nature  of  the  collection  system 
one  mcst  understand  collection  requirements.  This  chapter 
will  address  the  traditional  perspective  of  collection 
requirements,  describe  their  flow  through  a  collection 
system,  and  suggest  a  more  analytical  view  of  a  collection 
requirement. 

A.  SCPRCES  AND  TYPES  OF  COLLECTION  REQUIREMENTS 

A  collection  requirement  is  leveed  against  a  collection 
system  as  a  result  of  a  informational  need  identified  by  the 
user.  All  users  in  this  systems  structure  can  be  thought  of 
as  members  of  one  of  the  three  sub-elements  of  the 
Generalized  Intelligence  System.  Therefore,  ccllec+  on 
requirements  can  enter  a  collection  system  from  one  of  the 
following  three  sources: 

1  *  Requirements  System 

Collection  requirements  originating  from  a  require¬ 
ments  system  are  those  which  have  been  initially  identified 
as  requiring  some  degree  of  intelligence  collection  effort 
prior  to  being  satisfied.  An  example  of  such  a  requirement 
might  be: 

-  Determine  if  enemy  tanks  are  located  at  coordinates 
ABxxxxxx. 

An  intelligence  database  could  address  the  question  of 
wnether  cr  not  tanks  were  located  at  those  coordinates  at 
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some  point  in  time  in  the  past.  Collection  at  that  location 
in  near  real  time,  however,  must  be  accomplished  in  order  to 
answer  the  requirement  as  stated. 

2.  Analytical  System 


Collection  requirements  can  originate  from  an  anal¬ 
ysis  system  in  two  primary  fashions.  The  initial  evaluation 
of  the  intelligence  requirement  by  the  requirements  system 
as  primarily  analytical  in  nature  (its  dimensionality)  could 
have  teen,  to  some  degree  or  another,  incorrect.  An  anal¬ 
ysis  system  would, in  this  situation,  not  have  the  assets 
available  to  satisfy  such  an  ill-assigned  requirement  and 
would  be  forced  to  pass  the  requirement  onto  the  collection 
system  fcr  satis  fact icn.  An  example  of  such  a  requirement 
might  be: 

-  Notify  the  3rd  Erigade  if  there  is  an  increase  in 
moving  target  activity  in  their  sector. 

This  requirement  is  clearly  oriented  toward  a  surveillance 
(and  hence  collection)  activity.  An  analysis  system  would 
not  normally  have  under  its  operational  control  such  a 
surveillance  capability  and  thus  would  be  unable  to  effec¬ 
tively  respond  to  the  requirement. 

The  initial  intelligence  requirement  may  have  been 
primarily  analytical  in  nature  but  may  have  required  addi¬ 
tional  collected  information  to  enhance  or  upgrade  the 
quality  cf  analysis.  An  example  of  this  type  of  requirement 
is: 

-  Determine  the  capability  of  the  enemy  force  located  at 
coordinates  ABxxxxxx. 

This  is  clearly  an  analytical  requirement  yet  accurate 
collection  (to  determine  the  type  and  size  of  the  enemy 
force)  must  be  accomplished  in  order  to  more  accurately 
perform  the  analysis. 
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The  dif ferences  in  both  of  these  cases  described 
above  are  really  a  matter  of  degree.  The  first  case  alludes 
to  the  possibility  that  a  mistake  in  the  assignment  of 
requirements  may  have  teen  made.  The  second  case  concerns 
those  times  when  more  information  is  needed  to  satisfy  a 
given  requirement. 

3.  Collection  System 

A  collection  system  will,  in  order  to  maintain 
itself,  generate  collection  requirements.  These  are  the 
overhead  costs  of  the  collection  subsystems.  An  example  of 
such  a  requirement  is: 

Determine  radio  frequencies  the  enemv  is  using  to 
control  its  nuclear  capable  artillery. 

In  this  case  the  radic  frequencies  are,  in  themselves,  of 
little  intelligence  value  to  the  user.  However,  they  are 
vital  to  the  SIGINT  collection  subsystem  which  is  tasked 
with  providing  ether  forms  of  intelligence  concerning  such 
enemy  forces. 

In  order  to  speed  up  the  requirements  and  collection 
processes  special  types  of  collection  requirements  have  been 
developed.  The  most  common  of  these  are  listed  below: 

a.  Standing  Eequirements 

Standing  requirements  are  those  which  a  collec¬ 
tion  system  is  nearly  always  attempting  to  satisfy. 
Normally,  standing  requirements  are  applied  to  informational 
shortfalls  cf  obvious  importance. 

-  Enemy  nuclear  activity. 


Significant  enemy  movement  on  the  battlefield. 
The  location  of  enemy  command  posts. 


The  Army  has  traditionally  referred  to  these  sorts  of 
require ment s  as  EEI/CIR  standing  for  Essential  Elements  of 
Information  and  Other  Intelligence  Requirements. 

1.  Fast-Track  Requirements 

Fast-Track  Requirements.  Fast-track  requirements 
are  those  which,  because  of  their  time  sensitive  nature,  are 
allowed  to  by-pass  normal  collection  procedures. 

-  Verification  of  the  location  of  an  artillery  target. 

-  Deterioration  of  target  status  for  nuclear  target 

planning. 

-  Any  hot  requirement  of  importance. 

c.  Dedicated  Resources 

Often  portions  cf  or  an  entire  collection  system 
(or  subsystem)  will  be  allocated  for  use  by  a  single  user. 
Hhen  this  occurs  the  collection  system  becomes  a  dedicated 
resource.  An  example  of  this  type  of  allocation  might  be 
when  six  reconnaissance  sorties  (out  of  a  total  of  20  avail¬ 
able)  are  dedicated  for  use  by  a  single  maneuver  brigade. 
No  other  users  would  be  able  to  place  intelligence  require¬ 
ments  on  those  six  scrties  which  might  detract  from  tneir 
support  cf  the  manuever  brigade  to  which  they  are  dedicated. 
The  types  cf  collecticn  requirements  described  above  will  in 
this  study  he  referred  to  as  special  requirements. 

B.  TRADITIONAL  REQUIREMENT S  FION 

The  requirements  flow  into  any  given  type  of  collection 
system  (supporting  a  collection  subsystem  or  group  of 
collecticn  platforms)  can  be  depicted  as  shown  in  figure 
4.1.  Seme  points  shculd  be  ncted  when  viewing  this  figure. 


Special  variations  of  collection  requirements  initiated  in  a 
requirements  and  analytical  system  are  shown  as  inputs  into 
special  requirements.  This  is  not  meant  to  indicate  that 
special  requirements  not  related  to  those  systems  cannot 
exist  independently.  A  dedicated  resource  requirement  is  an 
example  of  such  an  independent  special  requirement. 
Additionally,  a  collection  system  requirement  can  be  thought 
of  as  totally  enclosed  within  the  collection  system.  Its 
primary  function  is  to  support  collection  platform  and 
system  operations  although  intelligence  information  gener¬ 
ated  from  its  application  would,  of  course,  not  be  ignored. 
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Figure  4.1  Beguirements  Flow. 

The  following  discussion  addresses  the  nature  of  the 
collection  requirement  as  it  relates  to  collection  subsys¬ 
tems  and  their  related  collection  platforms.  For  illustra¬ 
tive  purposes  the  first  portion  of  this  discussion  will 
address  the  relationship  of  a  single  collection  requirement 
as  it  enters  a  single  collection  subsystem  with  its  related 
platform  (s) .  An  example  of  such  a  collection  subsystem 
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might  be  the  Aerial  Reconnaissance  Subsystem  containing  such 
platforms  as  SLR  and  various  other  photographic  sensors. 

Traditionally,  a  collection  requirement  is  forwarded, 
for  the  most  part,  to  a  collection  subsystem  in  its 
entirety.  The  operators  of  the  particular  subsystem  and 
platforms  would  then  determine  how  the  collection  platforms 
under  their  management  might  be  able  to  satisfy  the  given 
requirement.  Occasionally,  a  collection  requirement  might 
be  well  suited  to  satisfaction  by  a  particular  subsystem  and 
platform.  On  other  occasions  there  may  be  little 
applicability. 

This  approach  toward  the  management  of  intelligence 
requirements  came  about  through  an  evolutionary  process. 
Factors  which  shaped  this  process  (and  which  will  not  be 
thoroughly  addressed  in  this  paper)  include: 

-  The  technical  orientation  of  specific  collection  plat¬ 
forms. 


elated  to 


-  Security  procedures  (compartmentation)  r 
specific  collection  platforms  and  subsystems. 

-  Multi-service  use  of  collection  platforms. 


-  The  limited  data  processing  capabilities  of  battle¬ 
field  users. 


-  Limited  communications  capabilities. 

There  are  advantages  and  disadvantages  associated  with  this 
platform  oriented  approach  toward  collection  management. 
The  operators  of  each  specific  collection  subsystem  are 
aware  of  the  intent  of  the  collection  requirement  and  are 
thus  better  able  to  operate  their  subsystem  to  satisfy  that 
intent.  Given  the  technical  nature  of  a  specific  collection 
subsystem,  an  argument  can  be  made  that  the  operators  of 
that  subsystem  are  best  capable  of  determining  which 
portions  of  a  given  intelligence  collection  requirement  can 
be  satisfied  by  their  subsystem  and  its  related  platforms. 


Disadvantages  tc  this  system  become  apparent  when 
looking  at  a  group  of  collection  subsystems  operating  under 
a  single  system.  This  is  the  more  realistic  situation.  A 
glympse  cf  the  potential  complexity  of  such  a  system  can  be 
seen  at  Figure  4.2.  Some  of  the  specific  disadvantages 
include  the  possibility  for  the  occurrance  of  uncontrolled 
redundancy  cf  effort  and  the  possibility  that  one  or  more 
collection  subsystems  can  become  saturated  with  collection 
requirements  while  ethers  operate  at  less  than  optimal 
levels  of  efficiency.  This  type  of  control  problem  can 
become  important  wher  one  considers  tne  fact  that  intelli¬ 
gence  information  is  generally  of  a  time  sensitive  nature 
and  hence  delays  in  satisfaction  of  a  requirement  will 
degrade  the  value  of  the  information  required  by  the  user. 

In  an  attempt  to  provide  some  sort  of  administrative 
contrcl  and  traceability  of  the  great  quantities  of  collec¬ 
tion  requirements  in  the  collection  system  a  collation 
process  has  evolved.  The  exact  structure  and  manner  in 
which  this  process  works  is  ad  hoc  and  varies  greatly  from 
unit  to  unit.  Some  processes  are  more  efficient  than 
ethers.  All  of  these  processes  do  have  some  features  in 
common.  First,  they  attempt  to  filter  out  unsuitable 
requirements.  Second,  they  attempt  to  keep  track  cf  which 
users  have  submitted  which  requirements.  Finally,  they 
attempt  to  get  appropriate  requirements  to  those  collection 
subsystems  which  may  be  able  to  satisfy  them. 

Once  collection  subsystems  have  responded  to  a  collec¬ 
tion  requirement  (through  platform  collection  or  perhaps  a 
negative  response)  then  a  sort  of  reverse  collation  process 
-  dubbed  Collection  Fusion  -  takes  place.  Similar  tc  the 
initial  collation  process  described  above,  one  goal  of  this 
process  is  to  match  information/intelligence  data  to  the 
users  that  requested  it.  Great  efforts  and  achievement  have 
teen  made  in  recent  years  in  the  area  of  collection  and 
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Figure  4-2  Composite  Collection  System. 

intelligence  fusion.  For  this  reason,  the  topic  of  collec¬ 
tion  fusion  will  not  be  addressed  in  detail  in  the  remainder 
cf  the  study. 

Thus,  most  collection  systems  deployed  by  major  units 
today  are  similar  in  structure  to  that  shown  in  Figure  4.3. 
Prior  tc  investigating  methods  which  could  improve  the 
collection  management  process  outlined  in  this  chapter  it  is 
first  necessary  to  examine,  in  more  analytical  detail,  the 
nature  of  a  collection  requirement. 
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Figure  4.3  Traditional  Collection  Management  Approach. 

C.  DICOMPOSITION  OF  A  COLLECTION  REQQIHEM  ENT 

Ccllection  reguirements  entering  a  collection  system 
are,  in  general,  net  in  a  form  which  collection  subsystems 
and  platforms  can  immediately  use.  Normally  the  reguirement 
must  first  be  re-expressed  into  more  familiar  terms  which 
have  a  mere  direct  relationship  to  those  tasks  wti  ich  subsys¬ 
tems  and  platforms  perform.  This  re-expression  process 
tends  to  narrow  tte  scope  of  the  original  ccllection 
reguirement  into  mere  manageable  portions.  Collection 


subsystems  subjectively  accomplish  this  re-expressicn  in 
many  collection  systems  found  in  use  today.  The 

re-expressicn  of  a  collection  requirement  into  a  set  of 
smaller,  more  manageable  subreguirements  will  be  referred  to 
in  this  study  as  the  decomposition  of  a  collection 
requirement . 

Upon  receipt  of  a  collection  requirement  a  given  collec¬ 
tion  subsystem  will  attempt  to  interpret  the  meaning  of  that 
requirement  in  terms  of  its  own  subsystem  and  related 
collection  platforms.  For  example,  given  an  incoming 
collection  requirement  of: 

-  Eetermine  if  tie  enemy  forces  located  at  X  are 
preparing  to  attack. 

An  aerial  reconnaissance  collection  subsystem  might  generate 
the  fcllcwitg  subrequirements: 

-  Take  an  aerial  photograph  of  location  X  to  determine 
if  the  enemy  located  there  is  in  an  attack  posture.* 

-  Provide  moving  target  radar  coverage  of  area  X  to 
determine  if  the  enemy  is  moving  toward  friendly  lines. 

Given  the  same  collection  requirement  a  signal  intelligence 
collection  subsystem  might  generate  the  following  subre- 
quireient: 

-  Intercept  the  radio  communications  of  enemy  units 
located  at  X  to  determine  if  they  are  preparing  to 
attack. 

It  is  possible  (and  in  practice  often  occurs)  that  a  collec¬ 
tion  subsystem  might  not  be  suited  to  such  a  collection 
operation  and  would  not  be  able  to  generate  any  feasible 
collection  subrequirements. 

Note  that  in  the  examples  provided  above  that  the  gener¬ 
ated  subreguirements  have  been  re-expressed  with  respect  to 
the  capabilities  of  the  collection  subsystem.  Also, 
although  each  subrequirement  appears  to  be  directed  toward  a 


single  collection  platform,  this  may  not  be  the  case.  For 
instance,  it  is  possible  that  several  subreguirements 
derived  from  a  single  collection  requirement  may  be  directed 
toward  the  same  collection  platform.  Finally,  each  of  the 
subreguirenents  in  the  example  are  basically  qualitative  in 
nature.  They  capture  the  nature  and  intent  of  the  original 
requirement  without  dealing  with  any  of  the  more  specific 
parameters  of  the  requirement. 

Taking  this  decomposition  process  one  step  further, 
consider  first  the  subreguirement  of  the  aerial  reconnais¬ 
sance  collection  subsystem  {labelled  with  an  astirisk 
above).  an  aerial  photographic  collection  platform  may 
decompose  that  subrequirement  in  the  following  manner: 

-  Provide  black  and  white, low  panoramic  and  vertical, 
photographs  of  location  X. 

-  Provide  black  and  white,  low  panoramic  and  vertical, 

rhctcgraphs  of  major  roads  leading  from  location  1  to 
he  nearest  friendly  forces. 

Although  these  subreguirements  are  certainly  ve^y  detailed 
(when  compared  tc  these  of  the  collection  subsystem) ,  they 
still  are  oriented  teward  the  satisfaction  of  the  nature  and 
intent  of  the  original  collection  requirement. 

The  subrequirements  addressed  in  the  preceeding  para¬ 
graphs  will  be  labelled  as  quality  subr eguirements.  Any 
given  collection  requirement  will  also  have  associated  with 
it  another  set  of  parameters  which  are  more  technical  in 
nature.  The  primary  example  of  such  a  technical  parameter 
is  the  time  restraint  associated  with  a  given 
subreguirement . 

Time  restraints  were  mentioned  briefly  in  Chapter  One  as 
they  pertained  to  general  intelligence  requirements.  Many 
of  the  same  concepts  apply  with  respect  to  the  decomposition 
of  collection  requirements  except  in  a  much  more  detailed 
fashion.  A  collection  requirement  enters  the  collection 
system  with  at  least  two  time  restraints  associated  with  it. 
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-  The  tine  by  whach  the  user  must  have  the  desired 
information.  This  restraint  tells  the  collection  system 
whet  the  collected  intelligence  must  be  in  the  user’s 
hands.  Commonly  used  terms  describing  this  restraint 
are  "best  possible"  or  "as  soon  as  possible"  (both  of 
which  provide  some  degree  of  system  flexibility)  and 
"net  later  than/not  earlier  than"  formats  (which  tend  tc 
be  acre  restrictive). 


-  The  desired  time  of  collection.  This  restraint  lets 
the  collection  system  know  that  the  value  or  quality  of 
the  collected  intelligence  i?  at  least  partially  depen¬ 
dent  upon  the  time  in  which  it  is  collected.  Formats  in 
comacn  use  tend  to  specify  a  point  in  time,  identify  a 
time  window  during  which  collection  should  be  accom¬ 
plished,  or  require  that  collection  be  accomplished 
continuously  fer  seme  length  of  time  (in  this  situation 
the  collection  function  becomes  more  of  a  surveillance 
function)  . 


These  technical  restraints,  similar  to  the  guality 
subrequirements,  must  be  expressed  with  respect  to  the 
specific  collection  subsystems  and  eventually  their  collec¬ 
tion  platforms.  There  exist  other  technical  restraints 
associated  with  any  given  collection  subrequirement.  These 
will  not  be  specifically  addressed  in  this  thesis  but  are 
considered  in  all  algorithm  development. 

A  single  collection  subrequirement  if  portrayed  graphi¬ 
cally  (and  decomposed  to  the  collection  subsystem  level) 
would  contain  information  describing  where  it  originated 
(some  sort  of  tag  associating  it  with  a  user  or  set  of 
users),  the  quality  or  nature  of  the  subrequirement,  the 
collection  subsystem  it  is  associated  with,  and  all  appro¬ 
priate  technical  restraints.  The  structure  of  a  subrequire¬ 
ment  might  look  like  that  shown  at  Figure  4.4.  As 
previously  mentioned,  the  decomposition  of  collection 
requirements  is  traditionally  accomplished  by  the  collection 
subsystem  relying  heavily  upon  expert  judgement  and  prior 
practices/stan da rd  procedures.  Therefore  the  subreguirement 
structure  depicted  above  should  be  viewed  at  this  point  in 
the  thesis  as  a  tool  to  enhance  understanding  of  a  collec¬ 
tion  subreguirement. 
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Figure  4.4  Subrequireaent  Structure. 


If  one  were  to  group  all  of  a  single  collection  require¬ 
ments  subreguirements  into  one  construct  it  might  appear  as 
that  shown  in  Figure  4.5.  The  collection  system  ,  in  this 
case,  consists  of  three  collection  subsystems  -  1,  2,  3. 
The  collection  requirement  originated  from  unit  number  2  and 
was  decomposed  by  the  collection  subsystems  into  three 
subrequirement  s. 
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Figure  4.5  Collection  Eequirement  Vector. 

It  could  be  demonstrated,  using  an  example  of  collection 
platform  requirement  decomposition,  how  this  process  can 
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continue  tc  the  highest  levels  of  resolution.  However,  this 
study  is  focused  on  the  relationship  between  the  collection 
system  and  subsystem  and  will  not,  therefore,  develop  the 
decomposition  methodology  any  further  than  that  already 
presented. 


D.  1  BE  INTELLIGENCE  COLLECTION  MANAGEMENT  PROBLEM 

The  collection  management  problem  is  a  resource  alloca¬ 
tion  problem.  Scarce  collection  resources  must  be  allocated 
toward  the  satisfaction  of  collection  reguirements.  This 
tnesis  suggests  that  the  traditional  approach  to  that 
problem  (as  depicted  at  Figure  4.3  and  discussed  in  previous 
chapters)  can  be  improved  greatly  with  some  minor  modifica¬ 
tions  to  the  functional  structure  of  the  current  system  and 
the  use  cf  a  mathematical  optimization  scheme.  The  struc¬ 
tural  modification  (and  resulting  efficiencies)  is  straight¬ 
forward  and  will  be  addressed  in  the  following  paragraph. 
The  optimization  scheme  is  more  complicated  and  will  be 
developed  in  Chapter  Four. 

The  primary  functional  change  suggested  by  the  previous 
discussion  is  that  cf  allocating  collection  resources  to 
satisfy  collection  reguirements  (and  perhaps  subreguire- 
ments)  from  the  collection  system  rather  than  the  collection 
subsystem  level.  In  order  to  perform  this  allocation  func¬ 
tion  collection  systems  must  posess  the  capability  of 
matching  sutreguiremerts  tc  collection  subsystems  (hence  a 
reguirement  decomposition  capability).  We  will  assume  for 
the  remainder  of  this  study  that  such  a  capability  can  be 
transferred  from  the  subsystem  to  system  level  with  little 
difficulty. 

Certain  efficiencies  and  advantages  result  from  this 
consolidation  functicn.  With  this  new  structure  reguire¬ 
ments  need  not  be  addressed  by  all  collection  subsystems. 


Figure  4.6  fiestructured  Collection  System. 


Cnly  those  requirements  (or  sutreguirements)  best  suited  for 
satisfaction  by  a  subsystem  would  be  forwarded  to  that 
subsystem  for  collection  action.  Unwanted  duplication  of 
effort  cculd  be  more  easily  limited  with  this  structure.  A 
more  balanced  use  of  all  collection  subsystems  cculd  be 
controlled  from  the  collection  system  level.  These  effi¬ 
ciencies  are  important  but  of  a  fairly  administrative 
nature. 

Tbe  real  advantage  of  this  structure  is  that  it  allows 
for  the  application  of  optimization  methods  to  the 


collection  resource  allocation  problem.  At  this  point  in 
the  collection  management  process  we  are  now  aware  of  the 
demands  (in  the  form  cf  requirements)  placed  upon  the  system 
and  cf  our  resource  constraints  (available  collection 
assets)  .  With  some  added  input  from  the  collection  subsys¬ 
tems  concerning  their  operational  capabilities  we  will  be  in 
a  position  to  apply  powerful  optimization  procedures  to  the 
allocation  problem.  These  procedures  will  be  addressed  in 
Chapter  Five. 


V.  THE  INTELLIGENCE  COLLECTION  MANAGEMENT  MODEL 


This  thesis  suggests  than  an  examination  and  analysis  of 
intelligence  collection  requirements  prior  to  the  actual 
allocation  cf  collection  platform  resources  will  lead  to  a 
more  intelligent  and  efficient  use  of  such  resources.  This 
portion  of  the  study  will  develop  a  mathematical  optimiza¬ 
tion  mcdel  which  is  useful  in  the  performance  of  such  anal¬ 
ysis.  Initially,  a  simplified  version  of  the  collection 
system  will  be  considered  in  the  development  of  this  mcdel. 
Modifications  to  the  basic  model  will  address  important 
intelligence  collection  concerns.  The  subject  this  model 
addresses  is  that  of  scarce  resource  allocation. 
Specifically,  in  what  manner  should  available  collection 
resources  be  allocated  to  best  satisfy  a  given  set  of  intel¬ 
ligence  collection  requirements. 

A.  THE  EASIC  COLLECTION  SISTEM  MODEL 

The  tasic  collection  system  model  is  described  below: 


MAXIMIZE : 


V  j 


(egn  5.1) 


SUBJECT  TO: 


1 


1 


<  b. 

] 


1,...,n  (i  is  the  index  for  collection  require¬ 
ments.  There  are  a  total  of  n  collection  require¬ 

ments  considered  in  the  requirement  set  of  the 
basic  model) 

1,„..,m  (j  is  the  index  for  collection  subsys¬ 
tems.  There  are  a  total  of  m  collection  subsys¬ 

tems  considered  in  the  basic  model) 

The  decision  to  allocate  collection  resource  j  to 
collection  requirement  i {0  =  no,  1  =  yes). 


The  amount  cf  collection  resource  j  allocated 
toward  the  satisfaction  of  collection  requirement 
i  if  d-.  =  1  (units  are  subsystem  collection 
hours  -  hr s) . 


Total  amount  of  subsystem  j  collection  resources 
available  for  use  is  satisfying  the  set  of  collec¬ 
tion  requirements  n  . 

Relative  importance  associated  with  requirement  i 
(priority).  Requirement  priority  will  not  be 
considered  in  the  basic  model  and  therefore 
=  1  in  the  basic  model.  Requirement  priority 
will  be  addressed  in  Section  B.2  of  this  Chapter 
where  values  cf  »■  will  be  allowed  to  vary. 


Expected  fraction  cf  requirement  i  satisfied  by 
those  collection  subsystems  (j  =  1,...,m)  tasked 
to  satisfy  that  requirement. 


Certain  assumptions  associated  with  this  model  should  be 
addressed.  The  simplified  collection  system  which  will  be 
the  basis  fcr  model  development  has  as  one  of  its  character¬ 
istics  a  fixed  number,  m  ,  of  collection  subsystems.  let 
be  defined  in  the  following  manner: 

s  •.  =  collection  subsystem  j  (for  j  =  1,...,m). 

Therefore  j  is  the  index  for  collection  subsystems.  The 
impact  of  the  fixed  collection  subsystem  assumption  is  that 
the  quantity  of  collection  subsystems  available  for  opera¬ 
tional  employment  by  the  decision  maker  does  not  change 
during  the  course  of  the  collection  resource  allocation 
decision  process.  This  collection  system  will  also  only 
consider  a  fixed  quantity,  n  ,  of  collection  requirements, 
let  r  be  defined  in  the  following  manner: 

r^  =  The  ith  collection  requirement  (for  i=1,...,n). 

Thus,  i  is  the  index  fcr  collection  requirements.  In  other 
words,  the  cumber  of  collection  requirements  under  consider¬ 
ation  dees  not  change  during  the  course  of  the  resource 
allocation  process.  An  additional  assumption  closely 
related  to  the  fixed  number  of  requirements  assumption 
concerns  the  timing  of  the  collection  decision.  For  the 
basic  mcdel  it  is  assumed  that  all  of  the  collection 
requirements  under  consideration  (rir  r2 ,  ...,rn)  will  have 
collection  resources  allocated  for  their  satisfaction  at  the 
same  time.  Furthermore,  the  results  (collected  data)  from 
all  collection  subsystems  (Sj  ,s2,..  )  will  reach  the 

appropriate  user  within  the  bounds  of  the  required  time 
restraints.  In  ether  words,  the  lead  and  lag  time  consider¬ 
ations  addressed  in  previous  chapters  are  not  considered  in 
the  basic  model. 


1 .  Cec isio n  Variables 

The  decision  variable  used  in  the  basic  model  is 

binary: 

0  if  subsystem  j  does  not  allocate  collection 
resources  to  satisfy  requirement  i. 

dir 

1  if  subsystem  j  does  allocate  collection 
resources  to  satisfy  requirement  i. 

This  implies  that  the  basic  model  will  only  determine 
whether  cr  not  it  should  allocate  a  predetermined  and  fixed 
amount  of  collection  resource  from  subsystem  j  toward  the 
satisfaction  of  requirement  i.  The  importance  of  this 
assumption  and  decision  rule  are  great.  It  does  net  allow 
the  model  to  vary  the  amount  of  collection  resource  it  allo¬ 
cates  toward  the  satisfaction  of  a  requirement.  It  either 
allocates  a  fixed  and  predetermined  amount  of  resource  (a-4) 
cr  none  at  all.  Collection  subsystems,  in  other  words,  can 
only  attempt  to  satisfy  a  collection  requirement  by  alio-  4 
eating  resources  in  ere  specific  manner.  At  first  glance, 
the  use  of  this  ftype  of  decision  variable  seems  to  be  a 
harsh  and  unrealistic  constraint  on  the  model.  Such  a 
perception  is  inaccurate. 

The  great  majority  of  tactical  intelligence  require¬ 
ments  fall  into  one  of  several  classes  of  requirements. 
Targeting  requirements  form  such  a  class.  In  order  to 
satisfy  a  targeting  requirement  the  collection  system  must 
basically  provide  the  user  (requestor)  with  information 
concerning  the  location,  dispersion,  nature  (its  type  of 
activity),  and  level  of  protection  (armored  or  not)  of  a 
potential  target.  Collection  subsystems  which  posess  the 
capability  of  at  least  partially  satisfying  targeting 
requirements  have  developed  SOPs  (standard  operating 
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procedures)  for  attempting  such  satisfaction.  Fcr  the 
majority  cf  such  targeting  requirements  these  SCPs  are 
closely  adhered  to  by  the  subsystems.  In  special  targeting 
situations  (as  in  nuclear  packages)  ,  of  course,  special 
subsystem  allocations  can  be  planned  and  employed.  This, 
however,  is  the  exception  rather  than  tne  rule.  Similar 
procedures  are  followed  fcr  other  classes  of  collection 
requirements. 

The  model  assumption  that  subsystems  can  only 
satisfy  a  requirement  in  one  particular  manner  is,  in  fact, 
more  closely  related  to  the  realistic  setting  than  previ¬ 
ously  expected.  It  applies  to  the  majority  of  typical 
collection  requirements.  Thus,  the  basic  model  developed  in 
this  study  should  be  considered  applicable  to  such  classes 
cf  requirements. 

There  exist  collection  requirements  to  which  the 
decisioc  variable  d . . is  not  well  suited.  Certain  require- 
ments,  for  instance,  can  be  satisfied  by  collection  subsys¬ 
tems  at  varying  levels  of  satisfaction  rather  than  at  a 
single  discrete  level  of  satisfaction  as  sugg^ted  in  the 
basic  model.  An  example  of  such  a  subsystem  might  be  that 
of  the  signal  intelligence  collection  subsystem.  Clearly, 
the  level  cf  satisfaction  of  certain  requirements  would 
increase  (to  a  point  of  diminishing  marginal  returns)  as 
more  hours  of  signal  intercept  time  are  applied  to  the 
satisfaction  of  the  requirement.  We  would  also  suspect  that 
this  level  of  effectiveness  function  might  be  continuous  and 
monotone  increasing  (i.e.  1.5  hours  of  intercept  time  cannot 
be  less  effective  that  1.0  hours  of  intercept  time).  In 
such  situations  a  more  suitable  decision  variable  x^j  should 
be  used. 

x.  .  =  The  amount  of  collection  resource  from  subsystem  j 

i] 

allocated  toward  the  satisfaction  of  requirement 

i. 
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The  application  of  this  type  of  decision  variable  to  the 
basic  model  will  be  addressed  in  Section  3.4  of  this 
chapter. 

2.  Resource  Constraints 

In  the  basic  model  it  will  be  assumed  that  each 
collection  subsystem  j  has  at  its  disposal  a  fixed  amount  of 
collection  resources.  Let  b^  be  defined  in  the  following 
manner: 


b^  =  The  total  amount  of  subsystem  j  collection 
resources  available  for  allocation  toward  the 
satisfaction  cf  collection  reguireaents. 


Thus, 


b3 


is  a  constant  in  the  basic  model. 


i  ..  are  subsystem  collection  hours.  Thus 
resource  constraints  cf  this  model  can  be  rep 
following  manner: 


The  units  of 
,  the  overall 
resented  in  the 


4 

V  j  (j  =  1 ,  .  .  .  ,m)  (e<3n  5*2) 

Let  a  .  .  be  defined  in  the  following  manner: 

1  j 

a.  .  =  The  amount  cf  collection  resource  i  allocated 
toward  the  satisfaction  of  collection  requirement 
i  if  d—  =  1  (in  subsystem  collection  hours)  . 

The  relationship  between  collection  subsystems  and 
collection  requirements  is  critical  to  this  model. 
Specifically,  collection  subsystems,  in  the  allocation  of 
their  specific  collection  resources,  contribute  to  the 
satisfaction  of  intelligence  collection  requirements.  There 


I 


d  .  .  a  .  . 
-j  i] 


<  b. 
3 
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are  several  ways  in  which  intelligence  collection  resources 
can  he  allocated.  For  example,  aerial  reconnaissance 
subsystem  resources  are  normally  allocated  in  terms  of  the 
number  cf  sorties  per  requirement.  Signal  intelligence 
subsystem  resources,  cn  the  other  hand,  are  often  allocated 
in  terms  of  the  number  of  positions  (where  the  term  position 
refers  to  operator  position)  and  the  quantity  of  monitoring 
time  per  requirement.  These  examples  indicate  that  collec¬ 
tion  resource  units  can  be  very  diverse.  In  order  to 
consider  the  multiple  collection  subsystem  resources  in  the 
basic  mcdel  it  must  be  shown  that  diverse  collection 
resource  units  can  be  transformed  (in  a  somewhat  reasonable 
manner)  into  subsystem  hours.  The  two  examples  cited  in 
this  paragraph  can  easily  be  transformed  into  similar  units 
(i.  e.  subsystem  collection  hours). 

A  typical  aerial  reconnaissance  sortie  may  last 
three  hours.  Of  that  three  hour  time  period  perhaps  only 
one  hour  can  be  used  for  actual  reconnaissance  time  (this 
reconnaissarce  time  is  normally  referred  to  as  time  on 
target  or  TCT)  .  If,  during  this  one  hour  TOT,  the  platform 
performed  its  aerial  reconnaissance  mission  against  two 
collection  requirements,  then  that  subsystem  could  be  said 
to  have  allccated  . 5  subsystem  collection  hours  to  each  of 
the  two  collection  requirements.  Note  that  the  calculated 
number  cf  subsystem  collection  hours  was  independent  of 
whether  cr  not  the  aerial  reconnaissance  subsystem  achieved 
success  in  its  mission  effort.  Therefore,  for  this  specific 
subsystem  the  following  relationship  holds: 


amount  of  TOT  (hours) 

a  of  intelligence  requirements 
collected  against  while  on  targe" 


(eqn  5.3) 


In  this  sense  a  4  can  be  interpreted  as  equaling  the  number 
of  aerial  reconnaissance  subsystem  collection  hours  consumed 
in  attempting  to  contribute  to  the  satisfaction  cf  collec¬ 
tion  requirement  i. 

Tactical  signal  intelligence  subsystems  typically 
have  at  their  disposal  many  operators  (analysts)  who  extra¬ 
polate  from  intercepts  and  other  signal  data  information 
relevant  to  the  satisfaction  of  collection  requirements. 
Each  operator  is  able  to  work  a  fixed  amount  of  hours 
performing  his  function.  If  two  subsystem  operators  each 
must  spend  four  hours  performing  their  function  in 
attempting  to  contribute  to  the  satisfaction  of  a  given 
collection  requirement  then  eight  subsystem  collection  hours 
have  teen  allocated  to  that  requirement.  The  following 
relationship  holds  with  respect  to  this  collection 
subsystem: 


(amount  of  subsystem 

hours  per  position)  x  (number  of  positions) 

(number  of  intelligence  requirements 
collected  against)  (eqn  5.4) 


The  interpretation  cf  a—  is  similar  to  that  of  the 
preceeding  example  -  the  number  of  signal  intelligence 
subsystem  collection  hours  consumed  in  attempting  to 
contribute  to  the  satisfaction  of  collection  requirement  i. 

It  is  a  simple  matter  to  make  allocation  calcula¬ 
tions  once  collection  has  already  occurred.  If  the  collec¬ 
tion  model  is  to  be  useful,  however,  it  must  be  able  to  aid 
the  decision  maker  prior  to  the  actual  allocation  of  collec¬ 
tion  resources.  To  do  so  this  model  therefore  requires  that 
a—  values  be  known  or  estimated  prior  to  the  resource  allo¬ 
cation  decision.  How  can  this  a  priori  estimation  of  a^  be 


Ihe  first  and  perhaps  most  simple  approach  to  this 
problem  is  to  have  the  subsystem  j  operators  subjectively 
estimate  a^  given  requirement  i.  The  advantage  to  this 
technique  is  that  the  expertise  of  the  subsystem  operators 
is  applied  to  the  a^4  estimate.  There  are,  however,  many 
disadvantages.  Included  among  them  are  inconsistanca.es  and 
inaccuracies  associated  with  subjective  estimates  (even  when 
competent  personnel  are  providing  the  estimates)  and  varia¬ 
tions  in  levels  of  expertise  found  among  the  operators  of  a 
given  subsystem.  Thus,  the  primary  disadvantage  to  the 
subjective  estimation  of  a .  .  is  that  the  quality  of  the 
estimate  is  far  too  dependent  upon  the  quality  of  the  oper¬ 
ator  providing  that  estimate. 

A  second  method  of  handling  this  estimation  problem 
is  through  the  establishment  and  use  of  norms  and  standard 
operating  procedures  (SOPs)  which  are  known  to  be  accurate 
or  at  least  reasonable.  For  instance,  a  SOP  may,  based  upon 
previous  experimental  data  and  experience,  specify  that  only 
a  predetermined  amount  (with  no  variation)  of  subsystem 
collection  hours  associated  with  collection  subsystem  j  will 
be  allocated  toward  the  satisfaction  of  any  given  collection 
requirement  i.  For  example,  such  an  SOP  might  allow  tor  the 
allocation  of  only  one  aerial  reconnaissance  sortie  (one 
subsystem  collection  hour)  for  any  single  collection 
requirement.  In  this  sort  of  a  system  the  estimation  of  a 
is  really  no  estimation  at  all  but  rather  a  decision  rule 
used  by  the  collection  system  decision  maker.  The  value  of 
such  a  system  depends  upon  its  ability  to  accurately  match 
all  requirements  with  appropriate  SOPs.  The  potential  weak¬ 
ness  of  such  a  system  depends  on  its  ability  to  handle 
diverse  types  and  classes  of  collection  requirements. 

A  third  method  involves  the  use  of  both  techniques 
addressed  above.  This  technique  allows  for  the  subjective 
estimation  cf  a- 4  (by  expert  subsystem  operators)  which  are 


at  the  same  time  boarded  by  norms  and  SOPs.  For  example,  an 
aerial  reconnaissance  subsystem  operator  may  be  authorized 
to  make  a  .  estimates  of  integer  subsystem  collection  hours 
less  than  three.  In  other  words,  he  is  not  authorized  to 
provide  non-integer  estimates  or  estimates  of  allocations  of 
three  hours  or  mere.  This  technique  is  often  used  in  prac¬ 
tice  vfcere  collection  subsystem  characteristics  often 
dictate  a  finite  set  of  possible  collection  allocations  (and 


would  therefore  dictate  estimates  of  a 


in  the  basic 


model).  This  system  appears  to  provide  a  reasonable 
approach  to  the  problem  of  a  priori  estimation  of  a,- 4  .  The 
wide  range  cf  possible  collection  resource  allocation  esti¬ 
mates  is  narrowed  by  subsystem  operating  procedures,  norms, 
and  standards.  Individuals  are  then  in  a  better  position  to 
provide  more  accurate  estimates  of  a.  ..  . 

From  this  discussion  we  conclude  that  the  estimate 
cf  the  amount  of  subsystem  collection  hours  associated  with 
collection  subsystem  j  in  contributing  to  the  satisfaction 
cf  collection  requirement  i  (a£4)  can  be  provided  by  the 
specific  subsystem  operators.  Furthermore,  such  an  estimate 
is  highly  dependent  upon  the  manner  in  which  a  specific 
collection  subsystem  can  allocate  collection  resources. 

3  •  Cbiective  Function 

There  are  two  major  components  of  the  objective 
function  in  the  basic  collection  model.  The  first,  v4  is 
defined  as  follows: 


^  *  The  relative  importance  associated  with  a 

collection  requirement  i  (priority). 


given 


In  the  basic  model  the  value  for  all  v ^  will  be  equal  to 
one.  Ihus,  an  assumption  inherent  in  the  basic  model  is 
that  all  requirements  to  be  satisfied  are  of  equal  relative 
importance  (equal  pricrity)  . 
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The  second  major  component  of  the  objective  function 


is  E,  . 


=  The  aggregated  effectiveness  of  requirement  i  with 
respect  to  all  collection  subsystems. 

This  component,  in  turn,  is  dependent  upon  several  ether 
factors  which  will  be  developed  in  the  following  paragraphs. 
The  first  factor  in  the  determination  of  aggregated  effec¬ 
tiveness  pertains  tc  the  effectiveness  of  a  collection 
subsystem  j.  In  attempting  to  satisfy  a  given  collection 
requirement  i,  collection  subsystem  j  interacts  with  seme 
measureable  form  of  enemy  activity.  For  instance,  a  pheto 
reconnaissarce  platform  takes  a  picture  of  a  location  on  the 
battlefield  (presumed  to  be  located  in  enemy  territory)  .  A 
communications  intercept  platform  monitors  certain  frequen¬ 
cies  cn  the  electromagnetic  spectrum  (hopefully  the  enemy  is 
transmitting  information  of  value  which  friendly  forces  can 
detect  on  such  frequencies)  .  Many  things  can  happen  which 
can  prohibit  these  interactions  from  occurring.  In  the 
photo  reconnaissance  situation,  for  example,  the  platform 
may  breakdown  prior  tc  its  TOT  or  worse  yet  may  be  shot  down 
by  the  enemy.  In  the  communications  intercept  case  the 
enemy  may  decide  to  operate  on  radio  silence  (i.e.  not  use 
those  monitored  frequencies  at  all).  In  both  situations, 
the  collection  effort  would  be  unsuccessful.  As  a  matter  of 
fact,  the  intended  interaction  with  enemy  activity  did  not 
cccur  at  all  (or  we  cannot  detect  whether  it  occurred)  . 
When  this  happens  we  say  that  the  collection  mission  has 
failed.  There  exist  measures  or  estimates  of  these  sorts  of 
failures  with  respect  to  different  types  of  collection  plat¬ 
forms  and  subsystems  under  a  variety  of  threat  and  opera¬ 
tional  conditions.  These  measures  are  often  represented  as 
a  probability.  In  our  situation  we  are  specifically  inter¬ 
ested  in  the  probability  of  mission  failure  (where  mission 


is  defined  as  collecting  the  information/data,  etc.  that  the 
platform  or  subsystem  intended  to  collect).  In  this  basic 
model  we  are  concerned  with  the  probability  of  success 
rather  than  failure  and  define  the  term  p.^  in  the  following 
manner: 


(■  v 


i] 


=  The  probability  that  collection  subsystem  j  will 


collect  the  data  it  intends  to  collect 
attempting  to  satisfy  a  requirement  i. 


in 


Notice  that  this  definition  does  not  imply  that  the  collec¬ 
tion  subsystem  actually  was  able  to  satisfy  the  collection 
requirement . 

The  second  factor  which  is  important  in  determining 
the  ef f ectiveness  of  a  collection  subsystem  pertains  to 
actual  satisfaction  of  the  collection  requirement.  Recall 
that  a  collection  subsystem  may  be  capable  of  satisfying 
all,  none,  or  a  portion  of  any  given  collection  requirement. 


The  term  f . .  is  defined  as: 


i] 


f  —  =  That  fraction  of  requirement  i  which  can  be  satis¬ 


fied  if  collection  subsystem  j  collects  the  data 
it  intends  tc  collect  in  attempting  to  satisfy 
requirement  i. 


Note  that  the  term  f^  is  of  the  form  of  a  conditional 
expected  fraction.  Consider  the  example  in  which  a  collec¬ 
tion  requirement  consists  of  four  primary  parts  (these  were 
referred  tc  as  quality  subrequirements  in  previous  chap¬ 
ters)  .  The  aerial  reconnaissance  system,  in  this  example, 
could  satisfy  two  of  those  four  subreguirements  if  it 
successfully  performed  its  collection  mission  (collected  the 
data  it  intended  to  collect).  Thus,  in  this  example,  the 


calculated  value  for  f^  would  be  0.5. 


For  simple  classes  of  requirements  the  determination 


of  the  value  of 


■n 


IS 


fairly  simple  matter  (as 


demonstrated  in  the  example  in  the  preceeding  paragraph). 
For  such  simple  classes  of  requirements  and  various  types  of 
collection  subsystems  it  would  be  theoretically  possible  to 
develop  ncrms  and  standards  useful  in  determining  such 
values.  Fcr  example,  in  the  class  of  simple  targeting 
requirements  cited  in  an  earlier  paragraph,  only  three  items 
of  information  were  required  for  satisfaction  -  target 
description,  nature,  and  level  of  protection.  For  this 
simple  class  of  requirements  tae  aerial  reconnaissance 
subsystem  is  capable  of  satisfying  all  of  the  subreguire- 
ments  given  that  the  intended  collection  occurs.  Therefore 
its  f •  4  value  with  respect  to  simple  targeting  requirements 
is  one.  For  more  complicated  classes  of  collection  require¬ 
ments  we  would  expect  that  the  determination  of  f^.  will  be 
more  difficult.  In  the  basic  model  under  consideration  it 
will  be  assumed  that  it  is  possible  to  determine  the  values 
of  all  f  •  •  for  the  requirements  under  consideration. 

The  term  which  represents  the  relationship  between 
satisfaction  of  a  given  collection  requirement  i  by  collec¬ 
tion  subsystem  j  can  now  be  identified  and  examined.  The 
term  e  -  is  defined  as  expected  level  of  requirement  satis¬ 
faction  as  given  by: 


e  .  . 


(egn  5.5) 


This  term  can  be  interpreted  in  the  following  manner:  If 
collection  system  j  is  allowed  to  allocate  resources  toward 
the  satisfaction  of  requirement  i,  then  e^  represents  the 
level  of  collection  requirement  satisfaction  we  might  expect 
to  receive  in  return.  The  calculation  of  e^  is  of  the  form 
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cf  a  probability  multiplied  by  a  conditional  expected  frac¬ 
tion  (both  values  are  bounded  by  zero  and  one)  yielding  an 
expected  value.  Thus  e^-  is  also  bounded  by  zero  and  1. 

Ifce  value  e^  represents  the  level  of  requirement 
satisf action  we  would  expect  to  receive  by  allocating 
resources  from  a  single  collection  subsystem  j  against  a 
single  collection  requirement  i.  Our  problem,  however, 
involves  multiple  collection  requirements  and  subsystems. 
In  order  to  solve  this  problem  we  must  be  able  to  aggregate 
over  both  requirements  and  subsystems.  We  will  first 
attempt  to  deal  with  the  total  effectiveness  of  a  given 
collection  requirement. 

a.  Aggregation  Over  Collection  Subsystems 

Let  E  .  he  defined  in  the  following  manner: 

E  =  The  expected  fraction  of  requirement  i  satisfied 

i 

by  all  collection  subsystems  (j  =  1,...,m). 

This  study  will  address  two  possible  methods  of  obtaining 
the  total  aggregated  effectiveness  -  denoted  E.  . 

The  first  approach  to  the  calculation  cf  2^  is 

through  the  simple  summation  of  e  .  .  values  and  will  be 

r  i] 

denoted  E,  .  Specifically: 


m 

Ei  =  X  eijdi:  (e3n  5-6) 

i  -  i 


Under  Host  envisioned  circumstances  one  would  not  expect  to 
ever  he  able  to  satisfy  a  requirement  by  any  factor  greater 


7  S 


than  10  0??-  (Jnf cr tucately,  this  specific  method  of  aggrega¬ 
tion  allows  for  that  to  occur.  Consider  the  simple  example 
in  which  a  given  collection  requirement  can  be  satisfied  by 
two  collection  subsystems.  In  this  example  the  value  of  e.. 

is  .75  and  e.„  is  .50.  If  the  decision  is  made  that  both 

1  z 

subsystems  will  allocate  their  resources  toward  the  satis¬ 
faction  of  that  ith  requirement,  then  according  to  the 
summation  procedure  the  total  expected  level  of  satisfaction 
for  that  ith  requirement  would  be: 


i 

i 


e  .  . 

i] 


j 


)  +  ( e 


(.75  •  1)  +  (.50  •  1) 


(eqn  5.7) 


1.25 


This  value  seems  difficult  to  interpret  given  the  proceeding 

i 

development.  An  obvious  explanation  for  the  E.  value 
greater  than  one  is  that  there  must  exist  some  amount  of 
collection  subsystem  overlap.  This  overlap  is  referred  tc  a 
redundant  coverage.  The  summation  technique  would  provide 
more  reasonable  results  if  only  one  collection  subsystem 
were  allowed  to  allocate  resources  toward  the  satisfaction 
of  a  collection  requirement.  If  this  condition  were  to  be 
applied  to  the  example  above  then  the  collection  requirement 
in  guestion  would  have  a  total  expected  level  of 
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satisfaction  equal  tc  either  I.  (.75)  or  2,.  (.50).  Of 
course,  this  is  not  an  aggregation  scheme  at  all.  Another 
situation  in  which  tie  summation  technique  may  be  a  reason¬ 
able  method  of  aggregation  is  when  we  are  certain  that  there 
is  no  possible  way  in  which  the  same  portion  of  a  collection 
requirement  can  be  satisfied  by  more  than  one  collection 
subsystem.  In  other  words,  for  a  given  requirement  i,  the 
f .  .  value  associated  with  one  collection  subsystem  j  must 
not  intersect  with  the  f..  value  associated  with  any  other 
collection  subsystem  j.  The  two  values,  in  a  probabilistic 
sense,  must  be  mutually  exclusive.  An  example  of  such  a 
situation  might  involve  a  collection  requirement  such  as: 

-  Shat  types  of  communications  systems  is  the  unit 

located  at  ABxxxxxx  using? 

It  is  likely  that  this  requirement  might  be  satisfied  by 
tasking  sensors  which  could  detect  and  locate  communications 
emmitters  on  separate  and  non-overlapping  portions  of  the 
electromagnetic  spectrum.  Thus,  no  more  than  one  sensor  or 
subsystem  could  satisfy  the  same  portion  of  the  collection 
requirement.  The  f^  values  associated  with  this  require¬ 
ment  and  their  respective  subsystems  would  be  mutually 
exclusive  and  the  summation  methodology  would  be  a  reason¬ 
able  method  of  aggregation. 

A  second  drawback  to  the  summation  method  of 
aggregation  is  that  there  exists,  using  this  technique,  no 
way  to  represent,  in  a  continuous  sense,  decreasing  marginal 
returns.  Specifically,  the  summation  function  tells  us  that 

more  resource  allocation  to  requirements  with  high  values  of 

r 

E.  is  always  a  good  thing  to  do.  In  fact,  we  can  see  that 
there  are  many  circumstance s  where  this  action  is  net  a  good 
thing  to  do.  Clearly,  there  exists  some  point  in  time  in 
which  additional  resource  allocation  to  satisfy  a  require¬ 
ment  which  may  already  be  totally  satisfied  is  not  produc¬ 
tive  and  in  fact  is  wasteful. 


8  1 


Thus,  fcr  reasons  of  interpretability  and 
because  the  summation  function  lacks  a  way  of  representing 
decreasing  marginal  returns  we  reject  it  as  a  method  of 
aggregating  values  of  e^..  over  collection  subsystems.  The 
next  method  of  aggregation  provides  a  solution  to  these  two 
difficulties. 

The  primary  drawback  to  the  previous  aggregation 
scheme  is  that  under  certain  conditions  it  would  produce 
aggregated  effectiveness  values  which  were  difficult  to 
interpret  and  could  not  adequately  represent  decreasing 
marginal  returns  associated  with  the  allocation  of  collec¬ 
tion  resources.  A  more  meaningful  scheme  would  be  one  in 
which  the  total  expected  level  of  satisfaction  for  a  given 
requirement  (when  collected  against  by  multiple  subsystems) 
would  be  bounded  by  one  and  could  thus  be  more  easily 
compared  with  percent  levels  of  requirement  satisfaction 
(i.e.  1003  satisfaction  would  be  the  maximum  attainable 
value  for  E  ) .  Furthermore,  we  would  like  to  see  the  total 
expected  level  of  requirement  satisfaction  increase  as  more 
collection  subsystems  are  tasked  toward  the  satisfaction  of 
a  given  collection  requirement  but  not  necessarily  in  a 
totally  linear  fashion.  In  other  words,  two  collection 
subsystems  ought  to  provide  more  satisfaction  than  one  tut 
they  could  never  provide  more  than  1003  requirement  satis¬ 
faction.  Intuitively  we  would  expect  that  the  lower  bound 
on  the  expected  level  of  requirement  satisfaction  (in  the 
case  where  two  subsystems  were  tasked  to  satisfy  a  given 
collection  requirement)  would  be  the  maximum  of  e.p  ) . 

If  we  interpret  the  value  of  (d .  .  x  e..  ) as  the 

i]  i] 

probability  of  achieving  satisfaction  of  requirement  i  by 
allocaticg  collection  resources  from  subsystem  j  then  the 
term: 
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(1 


d-^-  e^-  )  =  The  probability  of  not  achieving 

satisfaction  of  requirement  i  by 
allocating  collection  resources  from 
subsystem  j  (given  that  we  decide  to 
allocate  resource  from  j)  . 

If  we  also  consider  that  the  operation  of  one  collection 
subsystem  is  independent  of  the  operation  of  another  then 
the  probability  of  net  achieving  satisfaction  of  requirement 
i  by  allocating  collection  resources  from  m  collection 
subsystems  can  be  represented  in  the  following  expression: 

m 

TT  (1  -  (eqn  5.8) 

J  -1  j 

j  =  1 

Cf  course,  the  probability  of  achieving  satisfaction  of 
requirement  i  by  allocating  collection  resources  from  m 
collection  subsystems  is  actually  E^  which,  in  turn,  is 
given  by: 


m 

TT 

=  i 


c  i  - 


d  .  .  e  .  .  )  ) 

i]  -J 


(eqn  5.9) 


Ihis  second  technique  of  aggregating  e,-j  values  dees  indeed 
deal  with  the  shortcoming  of  the  summation  methodology. 
Specifically,  values  are  bounded  between  zero  and  one 
and  the  effects  of  dimishing  marginal  returns  are  inherent 
in  the  nonlinear  natcre  of  the  product  function. 


The  primary  cause  for  concern  with  respect  to 
this  aggregation  technique  is  the  assumption  of  independence 
cf  collection  subsystems.  We  are  concerned  that  two  or  more 
subsystems,  in  collecting  information  pertaining  to  the  same 
requirement,  might  he  dependent  upon  one  another.  This 
possibility  does  exist.  Say,  for  instance,  an  aerial  recon¬ 
naissance  platform  overflies  an  enemy  position  on  a  collec¬ 
tion  mission.  The  enemy,  in  response  to  that  overflight, 
ceases  all  electronic  emission  activity  (fearing  the  plat¬ 
form  was  capable  of  detecting  such  activity) .  An  electronic 
intercept  platform  collecting  that  enemy  unit's  emissions 
would  be  negatively  affected  by  the  aerial  reconnaissance 
platform's  overflight. 

Examples  such  as  these  are  hard  to  envision  hut 
in  fact  much  of  the  intelligence  operation  planning  process 
is  devoted  to  insuring  that  two  or  more  collection  opera¬ 
tions  do  not  conflict  or  interrupt  one  another.  The  point 
to  be  made  is  that  this  method  of  aggregation  seems  to  be  a 
reasonable  approach  as  long  as  the  collection  subsystems 
involved  are  independent  of  one  another. 

b.  Aggregation  Over  Collection  Requirements 

We  must  new  concern  ourselves  with  the  second 

aggregation  problem.  How  do  we  combine  2?  for  all  ccllec- 

1 

tion  requirements  under  consideration?  Let  5  be  defined  in 
the  following  manner: 

E  =  Total  level  cf  requirement  set  (n  requirements) 
satisfaction  given  collection  allocation  from  m 

m 

TT  ( 1  -  d.  ,e  ..  )  )  (eqn  5.  10) 

~  J  —  J 

i  =  i 


subsyste  ms. 

n 

*  I  V- 

i  =  1 
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In  this  model  we  are  summing  (ever  all  requirements)  the 
expected  level  cf  satisfaction  for  requirement  i  values 
(Equation  5.9)  developed  in  a  previous  discussion.  The 
range  of  this  new  value  would  fall  between  zero  and  n  (the 
total  number  of  requirements  equals  n) .  One  weakness  of 
this  representation  as  a  measure  of  total  requirement  set 
satisfaction  lies  in  the  fact  that  the  summed  values  are 
somewhat  difficult  tc  interpret.  For  instance,  one  has  no 
way  cf  determining  (from  this  value  alone)  which  require¬ 
ments  in  a  given  set  might  be  highly  satisfied  and  which 
requirements  in  the  same  set  might  not  be  highly  satisfied. 

In  other  words  one  should  examine  the  variance  of  the  values 

2 

cf  E .  .  In  the  simple  model  we  are  primarily  concerned  with 
the  aggregate  level  cf  requirement  satisfaction  and  will  not 
concern  ourselves  with  levels  of  satisfaction  of  individual 
requirements.  In  Section  B.2  of  this  chapter  we  consider 
the  case  in  which  collection  requirements  are  not  assumed  to 
he  of  egual  importance  and  hence  are  concerned  with  varying 
levels  cf  requirement  satisfaction.  An  additional  short¬ 
coming  is  that  the  formulation  assumes  that  there  is  no 
overlapping  of  collection  requirements.  Most  collection 
systems  indirectly  guard  against  this  sort  of  overlap  by 
grouping  together  (piggy-backing)  similar  requirements  into 
a  common  single  requirement.  Thus,  we  do  not  consider  such 
overlap  to  cause  major  difficulties  with  respect  to  the 
model.  Therefore,  despite  interpr etabi lity  and  overlaps 
shortcomings,  summation  does  appear  to  be  a  reasonable 
method  of  aggregating  the  levels  of  effectiveness  of  n 
collection  requirements. 

4.  Comments  on  the  3asic  Model 

The  basic  model  as  formulated  will  attempt  to  allo¬ 
cate  collection  subsystem  resources  to  requirements  in  a 
manner  which  provides  the  biggest  return  in  overall  E  (total 
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aggregated  ievex  of  requirement  satisfaction)  for  a  given 
allocation  (assuming  a  feasible  solution  can  be  found  for 

the  program).  Thus,  resource  allocations  will  be  made  to 

.  2 

those  requirements  whose  E.  contribute  the  most  tc  the 

1  2 

objective  function.  The  amount  of  E.  which  any  single 
requirement  can  contribute  to  overall  satisfaction  (E) 
increases  as  more  resources  are  allocated  toward  the  satis¬ 
faction  of  the  requirement  but  reaches  a  limit  of  one.  This 

2 

characteristic  results  from  the  manner  in  which  E.  is 
calculated.  Recall  Equation  5.9.  As  more  collection 
resources  are  allocated  to  the  satisfaction  of  requirement  i 

the  product  term  in  Equation  5.9  becomes  small.  The  term 

2 

El  ,  therefore,  approaches  one  as  a  limit  in  such  circum¬ 
stances.  Thus,  as  mere  resources  are  allocated  the  marginal 
return  of  such  allocation  decreases  until  such  time  as  allo¬ 
cation  tc  a  different  requirement  becomes  more  attractive. 

Cne  disturbing  aspect  of  this  basic  model  is  that  we 
have  no  guarantee  that  all  requirements  in  the  given  set 
will  he  satisfied  by  the  optimum  resource  allocation  scheme 
calculated  by  the  program.  For  instance,  allocation  of 
collection  resources  to  a  given  requirement  may  never  be 
more  attractive  (contribute  more  to  the  maximization  of  the 
objective  function)  than  allocations  to  other  collection 
resources.  In  such  a  situation  this  program  would  ignore 
requirement  i  in  favor  of  allocations  of  resources  to  ether 
requirements.  An  additional  limitation  (somewhat  related  to 
the  first)  is  that  we  have  no  control  over  the  level  of 
satisfaction  of  any  given  or  set  of  collection  requirements. 
In  other  words  this  program  cannot  deal  with  requirement 
priorities. 


E 


1 ABI ATICNS  OF  THI  BASIC  MODEL 


Recall  the  basic  model  developed  in  the  first  section  of 
this  chapter: 


MAX’ I  MI 


i  U  Z  U  w  V-  - 


n 


(egn  5.11) 


d • .  =  C  or  1 


i 


=  1,...,n  {i  is  the  index 
nents.  There  are  a  total 
ments  considered  in  the 
basic  model) 


for  collection  reguire- 
o£  n  collection  reguire- 
reguirement  set  of  the 


j  =  1,...,m  (j  is  the  index  for  collection  subsys¬ 
tems.  There  are  a  total  of  m  collection  subsys¬ 

tems  considered  in  the  basic  model) 


The  decision  to  allocate  collection  resource  j  tc 
collection  reguirement  i (0  =  no,  1  =  yes) . 


a.  .  =  The  amount  cf  collection  resource  j  allocated 

i] 

toward  the  satisfaction  of  collection  reguirement 


i  if  d-  =  1  (units  are  subsystem  collection 
hours  -  hrs)  . 

lotal  amount  of  subsystem  j  collection  resources 
available  for  use  is  satisfying  the  set  of  collec¬ 
tion  require  Bents  n  . 

Relative  importance  associated  with  requirement  i 
(priority)  .  Requirement  priority  will  net  be 


considered 


the  basic  model  and  therefore 


v.  =1  in  the  basic  model.  Requirement  priority 
will  be  addressed  in  Section  B.2  of  this  Chapter 
where  values  of  v.  will  be  allowed  to  vary. 


Expected  fraction  of  requirement  i  satisfied  by 
those  collection  subsystems  (j  =  I,...,®)  tasked 
to  satisfy  that  requirement. 


1  •  Insuring  Levels  of  Requirement  Satisfaction 

A  primary  drawback  to  the  basic  model  can  be  handled 
using  a  similar  problem  formulation.  If  possible  we  would 
like  to  be  able  to  satisfy  all  collection  requirements  in 


the  total  set. 


In  order  to  insure  this  we  could  add  to  the 


above  formulation  additional  non-negativity  constraints.  A 
modified  formulation  containing  such  restraints  is  described 
below : 


MAXIMIZE: 


2 

v  .  E  . 


(eqn  5.  12) 


> 


n 


<  b . 


v 


d . .  =  0  or  1 
1  ] 


k^  =  An  aspiration  level  of  individual  requirement 
satisfaction. 

2 

This  formulation  will  insure  levels  of  E.  greater  than  k 

i 

for  all  collection  requirements  i  (at  least  some  minimum 
level  of  requirement  satisfaction)  .  He  remain  uncertain, 
however,  of  the  ultimate  level  of  requirement  satisfaction. 
Cne  can  easily  imagine  an  iterative  type  process  which  would 
increment  the  value  cf  k^  between  successive  runs  of  the 
program  until  a  feasible  solution  can  no  longer  be  obtained. 
The  gcal  of  this  iterative  process  would  be  to  determine  the 
highest  levels  of  satisfaction  at  which  all  requirements 
could  be  feasibly  satisfied.  One  must  realize  that  the 

final  levels  will  be  dependent  upon  the  scaling  factors  (k^  , 
k9,...,  kn)  imposed  by  the  program. 

There  is  a  fundamental  difference  between  this  model 
and  the  basic  mcdel  cutlined  in  Section  A  of  this  Chapter. 
The  basic  mcdel  is  guaranteed  to  have  a  feasible  scluticn. 
All  requirements  in  the  set  may  not  be  satisfied  to  a  mini¬ 
mally  desireable  level  but  the  model  will  find  a  solution. 
The  constraints  placed  upon  the  basic  model  (as  outlined  in 
this  section)  may  eliminate  the  possibility  of  finding  a 
feasible  resource  allocation  scheme. 

Given  this  fact  it  may  be  reasonable  to  approach  the 
solution  cf  this  problem  in  an  iterative 


manner 


use  tie  solution  to  the  basic  model  as  a 


Specifically, 

starting  point  upon  which  small  iterative  improvements 
(through  the  increase  in  k  ,•  values)  are  made.  This 
approach  in  itself  dees  not  guarantee  a  feasible  solution. 
It  dees,  however,  allow  for  the  initial  introduction  cf  k  ; 
constraints  into  the  problem  at  low  levels  which  will  hope¬ 
fully  lead  to  feasible  allocation  solutions.  A  primary 
drawback  to  this  approach  is  that  it  requires  some  level  of 
human  interaction  which,  of  course,  slows  down  the  process 
cf  solving  the  problem. 

A  different  approach  to  this  same  problem  is  to 
formulate  the  model  in  the  following  manner: 


d . .  =  0  or  1 
i] 


Zkn-  =  The  highest  attainable  level  of  individual 

requirement  satisfaction. 

The  value  Z  in  this  formulation  serves  as  a  scalar  multiple 
of  the  individual  requirement  aspiration  levels  (k.-  )  .  Thus, 
this  formulation  maximizes  the  value  of  Z  and  in  doing  so 
maximizes  the  the  level  of  individual  requirement 


satisfaction  subject  to  the  aspiration  levels  (k-_,  k~,..., 

k„)  imposed  on  the  pregram. 

2.  F.eq uirement  priorities 

The  prioritization  of  collection  requirements  serves 
as  an  important  management  function  and,  as  Appendix  A 
suggests,  as  a  possible  means  of  providing  intelligent 
control  of  the  collection  process.  We  know  that  it  is 
possible  tc  prioritize  a  given  set  of  collection  require¬ 
ments  (see  Appendix  A).  We  must  be  able  to  incorporate  seme 
such  ranking  scheme  into  the  optimization  process. 

There  are  twe  approaches  toward  modifying  the  basic 
model  once  we  have  decided  that  one  requirement  may  be  acre 
important  than  another.  The  first  approach  is  to  insure 
that  the  more  important  requirement  is  allocated  collection 

resources  in  such  a  manner  that  its  level  of  satisfaction 

2 

(E,-  )  is  greater  than  that  of  the  less  important  require¬ 
ment.  The  second  approach  is  to  insure  that  the  objective 
function  of  the  model  takes  into  account  the  fact  that  one 
requirement  is  more  important  than  the  other  when  it  maxim¬ 
izes  the  overall  level  of  requirement  set  satisfaction  (E)  . 
Each  of  these  two  approaches  are  addressed  in  the  following 
sect iens. 

a.  Prioritizing  OsiDg  Levels  of  Requirement 

Satisfaction 

There  are  several  approaches  to  insuring  mere 
important  requirements  acheive  higher  levels  of  requirement 
satisfaction  than  less  important  requirements.  Taking  the 
formulation  developed  in  Equation  5.12: 

n  m 

MAXIMIZE:  E  =  Y  v.C  1  -  TT  (-1  - 


d  .  .  e  .  .  )  ) 


He  have  modified  the  program  at  Equation  5.12  by  creating 
constraints  which  correspond  to  the  levels  of  priority  in 
cur  priority  system  (in  this  case  there  are  three  priori¬ 
ties  -  high  (h)  ,  medium  (m),  and  low(l)).  Specifically,  we 
have  determined  that  we  desire  that  the  high  priority 
requirements  in  the  total  set  be  satisfied  at  the  .9  level, 
medium  priority  requirements  at  the  .7  level,  and  low 
priority  requirements  at  the  .5  level.  Certain  aspects  of 
this  formulation  cause  concern.  That  concern  revclves 
around  the  relationship  between  low,  medium,  and  high 

priority  requirements.  For  example,  in  the  above  formula- 

2 

tion  we  reguire  ^  for  all  low  priority  requiremeEts  must 
be  greater  than  cr  equal  to  .5  and  those  for  medium  priority 
requirements  be  satisfied  at  a  level  greater  than  or  equal 
to  .7.  As  a  result  of  these  constraints  we  should  expect  to 
see  that  high  priority  requirements  are  satisfied  at  values 
greater  than  or  equal  to  the  value  .9.  What  we  do  not  know 
is  what  will  happen  to  our  overall  E  (and  satisfaction 
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This  observation  suggests  that  we  examine  the 
sensitivity  of  the  manner  in  which  we  allocate  resources  to 
collection  requirements.  One  way  to  accomplish  this  sort  of 
examination  is  to  approach  the  prioritization  of  the  collec¬ 
tion  requirement  set  in  a  somewhat  different  manner. 
Suppose  we  partition  the  rank  ordered  requirement  vector  (R) 
returned  by  the  process  outlined  in  Appendix  A  into  three 

sections  -  R  ,  R  ,  R,.  High  priority  requirements  are 

1  m  h 

elements  of  R^,  medium  priority  requirements  are  elements  of 

R  ,  and  low  priority  requirements  are  elements  of  R,  .  It  is 

m  1 

certainly  desireable  that  high  priority  requirements  (R  )  be 

n 

allocated  resources  in  such  a  manner  that  their  respective 
levels  of  satisfacticn  are  high.  To  insure  that  this  can  be 
accomplished,  irrespective  of  all  Rm  and  R^  requirements,  we 
formulate  the  following: 


n 


2 

i  =  1 


v.  (  1  - 


i  I 


Cl  - 


d .  .  e  .  . )  ) 

i:  i- 


2  OBJECT  TO: 


:.  >  .3  V.  e  R, 

l  i  Ti 


(eqn  5.15) 


-.•4  =  -  or  1 

If  such  a  program  proves  to  provide  a  feasible  solution  then 
we  will  knew  exactly  what  levels  of  satisfaction  (E*  )  for 
all  requirements  and  that  those  reguirements  we  identified 
as  having  a  high  priority  will  have  2?  values  of  at  least 
.9.  The  next  step  in  the  iterative  process  is  to  add  levels 
of  satisfaction  constraints  to  the  program  for  these 
reguirements  we  have  identified  as  having  a  medium  priority. 
This  formulation  would  appear  as  follows: 


MAXIMIZE: 


n 


m 


E=  V  v.  (1-  ~[J  (1  -  d..e..)) 

L*  i  '  i]  n 

i  =  1  -  =  1 


E.  >  .9  V.  e  P, 
i  l  Ti 


E.  >  .7  V.  E  R 
l  m 


E .  >  0.0  V .  e  R. 
i  l  1 


(egn  5.  16) 


WHERE: 


m 


e.  =  c  i  -  yy  a  -  d.  .e. .)) 

i  11  n  13 

i  =  1 


n 


V  d  .  .  a  .  .  <  b  .  Vn 

4.  1]  1]  ] 


i  -  1 


=  0  or  1 


d.  . 
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If  this  "upgraded"  program  provides  a  feasible  soiuticr.  we 
know  that  requirements  which  are  elements  of  P,  and  8  will 
be  satisfied  at  levels  of  .9  and  .7  respectively  and  that 
all  ether  requirements  will  at  least  be  minimally  satisfied. 
Cnee  this  iteration  has  taken  place  it  is  possible  to 
examine  the  sensitivity  of  adding  the  B  level  of  satisfac¬ 
tion  constraints.  If,  for  instance,  we  fail  to  find  a 

feasible  solution  after  the  addition  of  the  P.  constraints 

m 

then  we  know  that  this  infe asitility  was  caused  by  the  addi¬ 
tion  of  the  constraints.  He  may  also  discover  that  by 
levying  these  constraints  we  have  reduced  the  levels  of 

satisfaction  of  the  lower  priority  requirements  (P,  )  to  such 

1. 

a  level  that  resource  allocation  to  them  would  not  be  worth¬ 
while.  He  may  also  discover  that  the  solution  is  satisfac¬ 
tory  and  continue  onto  the  final  iteration  of  the  process 
which  would  be  to  add  level  constraints.  At  this  point 

in  time  the  program  becomes  identical  to  that  shown  at 
Equation  5.  14, 

There  are  many  advantages  to  this  iterative 
approach.  It  is  extremely  flexible  and  could  easily  be 
adapted  to  a  wide  variety  of  prioritization  schemes.  In  the 
early  stages  of  the  iterative  process  there  is  a  greater 
liklihood  of  finding  a  feasible  solution  to  the  problem 
because  the  constraints  on  the  program  are  less  severe  than 
those  associated  with  the  formulation  at  Equation  5.14. 
However,  a  feasible  solution  to  a  problem  formulated  with 
such  constraints  (as  alluded  to  in  previous  discussion)  is 
not  guaranteed.  Additionally,  this  iterative  process 
requires  time  and  interaction  with  human  decision  makers. 
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1,  =  A  scalar  representing  the  priority  value  cf  the 

ith  requirement. 

In  this  case  the  values  of  v-  would  not  ail  he  equal  to  one. 

There  are  numerous  ways  in  which  the  values  of 
V'  can  be  scaled.  The  most  appealing  method  is  to  let  the 
most  important  requirement  in  the  set  equal  one  and  all 
others  (in  rank  order)  be  values  less  than  one  but  greater 
than  zero.  In  the  event  many  requirements  were  being 
considered  in  the  set  it  may  be  wise  to  group  those  require¬ 
ments  of  siailar  importance  (i.e.  in  groups  of  high,  medium, 
and  lew  importance)  and  weight  the  groups  appropriately. 
The  effect  cf  this  sort  of  scheme  is  that  the  value  of  E  is 
increased  to  a  greater  degree  by  higher  priority  (more 
heavily  weighted)  requirements  than  lower  priority  require¬ 
ments.  Thus,  the  program  in  its  allocation  process  will 
emphasize  the  satisfaction  of  those  requirements  of  higher 
priority.  This  type  of  formulation  will  lead  to  a  feasible 
allocation  solution  to  the  model  considering  requirement 
prior^ies.  However,  once  again  we  are  uncertain  as  to  the 
minimum  levels  of  requirement  satisfaction  which  will  be 
obtained  using  such  a  formulation. 

The  problem  of  requirement  priorities  can  be 
addressed  through  mcdification  of  the  basic  model  in  two 
basic  manners  -  by  adding  constraints  to  the  basic  model,  or 
modifying  the  objective  function  of  the  basic  model.  Each 
technique  has  its  theoretical  advantages  and  disadvantages. 
The  usefullness  of  either  approach  would,  therefore,  be 
determined  by  the  actual  situation  in  which  they  might  be 
applied. 

3.  Redundancy  of  Collection  Cove  rage 


at  least  two  separate  collection  subsystems  (or  platforms) 
are  tasked  to  satisfy  certain  important  collection  require¬ 
ments-  The  model  developed  to  this  point  in  the  discussion 
is  unable  to  guarantee  to  the  user  that  any  quantity  of 
subsystems  ether  than  one  will  be  used  to  satisfy  a  given 
collection  requirement.  A  method  of  handling  this  diffi¬ 
culty  is  tc  add  additional  constraints  to  the  formulation. 
Cnee  the  decision  maker  has  decided  which  requirements 
should  he  the  subject  of  redundant  coverage  (R^  will  indi¬ 
cate  the  subset  of  R  which  require  redundant  coverage)  then 
restraints  such  as: 


:  =  i 


¥  i  e  R 


(eqn  5.  18) 


could  be  added  to  the  formulation  outlined  at  Equation  5.  14. 
Cne  must  remember  that  the  more  restraints  which  are  added 
to  a  program  decrease  the  chance  of  discovering  an  optimum 
solution  and  may  decrease  the  quality  of  a  feasible  solu¬ 
tion.  Thus  a  more  reasonable  approach  to  the  redundancy 
issue  might  also  involve  an  iterative  and  interactive 
approach.  For  irstarce,  once  the  user  is  satisfied  with  the 
resource  allocations  with  respect  to  the  priority  of  the  set 
of  collection  requirements  (as  discussed  in  previous  para¬ 
graphs)  ,  he  might  then  examine  those  allocations  to  deter¬ 
mine  where  redundancies  of  coverage  already  exist.  Recall 
that  an  increase  in  levels  of  satisfaction  (E*  )  may  be  the 
result  of  the  allocation  of  multiple  collection  subsystems. 
As  a  result,  some  of  the  collection  requirements  may  already 
be  satisfied  by  multiple  subsystems  in  the  existing  feasible 
solution.  Further  mere,  those  most  likely  to  have  such 


multiple  coverage  are  the  more  important  requirements  (from 
a  priority  point  of  view).  If  the  decision  maker  is  satis¬ 
fied  with  the  allocation  scheme  no  further  constraints  need 
he  applied  to  the  program.  However,  if  unsatisfied,  the 
decision  maker  can  apply  constraints  (such  as  those  shown  at 
Equation  5.18)  in  a  piecewise  fashion,  compare  new  alloca¬ 
tions  with  previous  allocation  scnemes,  and  decide  which  set 
of  resource  allocations  is  tetter  suited  to  the  collection 
problem  at  hand. 

4 .  Ose  of  a  Continuous  Decision  Variable 

Khen  we  decide  that  the  collection  subsystems  in  the 
system  can  allocate  collection  resources  in  a  continuous 
manner  (as  opposed  tc  allocation  of  resources  in  discrete 
packages)  then  the  continuous  decision  variable  model 
described  below  is  useful: 


MAXIMIZE: 
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=  1,...,m  (j  is  the  index  for  collection  subsys¬ 
tems.  There  are  a  total  or  a  collection  subsys¬ 
tems  considered  in  the  model) 


=  The  amount  cf  collection  resource 


allocated 


toward  the  satisfaction  of  collection  requirement 
i  (units  are  subsystem  collection  hours  -  hrs)  . 

b_.  =  Total  amount  of  subsystem  j  collection  resources 

available  for  satisfying  all  collection  require¬ 
ments  (i  =  1 ,.. . ,n)  . 


v^  =  Eelative  importance  associated  with  requirement  i 


(priority) . 


=  Expected  fraction  cf  requirement  i  satisfied  by 
all  collection  subsystems  (j  *  1,...,m). 

There  is  a  difference  between  this  model  and 
previous  models  developed  in  the  study.  Before,  we  were 
concerned  with  the  management  cf  collection  resources  given 
a  way  in  which  we  were  allowed  to  allocate  each  resource 
(a-,-  -:  )  •  Thus,  we  were  mixing  fixed  amounts  of  assets  to 
obtain  an  optimal  solution.  In  the  continuous  model  we  are 
managing  not  only  the  mix  of  assets  but  also  the  quantity  of 
asset  used  in  the  mix.  Thus,  the  continuous  decision  vari¬ 
able  model  should  be  viewed  as  a  much  more  absolute  model  in 
terms  cf  controlling  the  collection  subsystems. 

Because  we  are  controlling  how  much  of  a  given 
resource  ought  to  be  allocated  toward  the  satisfaction  of  a 
given  requirement  the  the  binary  decision  variable  d^  and 
the  predetermined  and  fixed  amount  of  collection  resource 
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a.-,  ai€  not  included  in  the  continuous  decision  variatle 
model.  In  their  place  we  have  introduced  the  continuous 
decision  variable  x: ■  (defined  above). 

Eecause  the  amount  of  collection  resource  which  can 
be  allocated  toward  the  satisfaction  of  a  collection 
requirement  is  new  variable  we  must  re-evaluate  the  defini¬ 
tions  of  quantities  which  are  dependent  upon  x:.. 

The  e n-  4  ten,  previously  defined  for  the  discrete 
(basic)  model  was: 


e  . 


(eqn  5.20) 


It  was  interpreted  to  be  the  level  of  satisfaction  with 
respect  to  requirement  i  we  might  expect  to  receive  in  the 
event  collection  resource  j  were  allocated  toward  require¬ 
ment  i.  In  the  discrete  model  situation  a^  was  predeter¬ 
mined  and  fixed.  In  the  continuous  decision  variable  mcdel, 
x^j  is  a  variable  and  thus  p  ^  ,  f and  consequently  e-^ 
are  all  functions  of  x...  The  term  e,,,...  is  defined  as 
follows : 


CXi  - ) 


(eqn  5.21) 


P(Xij)=  'I^e  Probability  that  collection  subsystem  j  will 
collect  the  data  it  intends  to  collect  in 
attempting  to  satisfy  requirement  i  expending 
x^  collection  resources. 
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That  fraction  of  requirement  i  which  can  be 
satisfied  if  collection  subsystem  j  collects  the 
data  it  intends  to  collect  in  attempting  to 
satisfj  requirement  i  allocating  x—  collection 
resources. 


The  expected  fraction  of  requirement  satisfaction 


(f^Xi-;))  now  a  function  of  hew  much  resource  we  allocate 
towards  the  satisfaction  of  a  given  intelligence  require¬ 
ment.  Onder  most  circumstances  we  would  expect  that  the 
fraction  of  the  requirement  satisfied  would  generally 
increase  (from  some  minimum  value)  to  a  maximum  possible 
fractional  level  of  satisfaction.  It  is  hard  to  imagine  a 
case  in  which  more  collection  resource  allocation  would 
actually  decrease  the  expected  level  of  requirement  satis¬ 
faction.  Thus,  this  function  is  assumed  to  be  monotonic 
nondecreasing. 

The  probability  that  a  collection  subsystem  collects 
the  data  it  intends  to  collect  (P(xij))  is  also  a  function 
of  The  possibility  exists,  given  this  functional  rela¬ 
tionship  between  P(xij)  an<i  that  the  probability  a 
collection  subsystem  collects  the  data  it  intends  to  collect 
may  decrease  as  a  function  of  x^j.  Consider  the  example  of 
an  aerial  reconnaissance  sortie  over  an  enemy  position  (i.e. 
a  threat  exists  to  the  survivial  of  the  platform).  To 
increase  x  (the  aacunt  of  collection  resource  allocated) 
this  platform  may  have  to  overfly  the  enemy  position  several 
times.  In  doing  so  the  platform  increases  its  vulnerability 
to  the  enemy  threat  and  reduces  its  chances  of  returning  its 
collected  data  to  the  subsystem  operators.  Thus,  as  the 
collection  platform  allocates  more  resources  toward  the 
satisfaction  of  the  requirement  its  resulting  p ( x i j )  value 
decreases.  Accordingly,  the  value  of  ®(yp-i)  which  depends 


upon  p 


could  also  decrease  as  x 


increases . 


This 
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observation  is  difficult  to  interpret  -  as  lore  collection 
resources  are  tasked  toward  the  satisfaction  of  of  a 
requirement,  the  expected  level  of  satisfaction  cf  that 
requirement  appears  to  decrease!  There  is  a  way  around  this 
difficulty.  He  can  consider  that  the  above  example  (and 
ethers  similar  to  it)  is  not  suited  for  use  in  a  model  using 
continuous  decision  variables.  This  assumption  is  fairly 
reasonable  if  we  interpret  (using  the  example  above)  each 
pass  of  the  surveillance  platform  as  a  specific  a,-.:  value  (a 
discrete  amount  of  collection  resource)  and  that  we  must 
decide  after  each  pass  whether  or  not  we  want  another  one. 
This  interpretation  allows  us  to  consider  the  aerial 
surveillance  example  with  discrete  rather  than  continuous 
decision  variables. 

The  observations  and  discussion  in  the  previous 
paragraph  allude  to  the  difficulty  in  interpreting  the  value 
P(Xi^)  the  continuous  decision  model.  Specifically,  what 
type  cf  collection  subsystems  (platforms)  are  suited  to  such 
a  model  and  how  dc  we  determine  P(xi^)  for  an  unknown 
x—  ?  The  continuous  decision  model  is  best  suited  to 
those  collection  subsystems  which  are  oriented  towards  a 
surveillance  activity.  In  other  words,  those  subsystems 
which  mcritcr  some  fora  of  enemy  activity  for  a  period  of 
time  would  therefore  itself  be  a  function  of  time  on 
target  -  TCT).  The  requirements  such  subsystems  might  be 
tasked  to  collect  information  cn  would  probably  be  somewhat 
time  dependent.  For  instance,  a  SLfi  (side  looking  radar) 
might  be  asked  to  determine  the  direction  of  enemy  advance. 
The  probability  that  the  SLR  subsystem  could  determine  that 
information  would  increase  as  TOT  increased  (and  conseq¬ 
uently  x^j  increased).  Determination  of  these  sorts  of 
^(Xi4)  va^ues  M0Uld  be  difficult  and  probably  could  cnly  be 
addressed  with  the  use  of  empirical  data  or  perhaps  from  a 
simulation. 


In  this  model  we  are  determining  which  collection 
subsystems  ought  to  allocate  resources  to  which  requirements 
and  also  how  much  of  those  resources  ought  to  be  allocated 
towards  the  requirement.  This  is  a  fundamental  difference 
from  the  basic  (discrete)  model.  It  (the  continuous  model) 
can  be  viewed  as  a  relaxation  of  the  basic  model  in  that  we 
are  no  longer  concerned  with  collection  resource  packaging 
constraints  but  rather  in  allocating  collection  resources 
along  a  continuum. 


VI.  APPIJISG  THE  INTELLIGENCE  COLLECTION  MANAGEMENT  MODEL 


A.  INTRODUCTION 

Three  important  assumptions  were  made  in  the 
development  of  the  basic  model.  They  were: 

-  Only  a  fixed  number  of  collection  requirements  (n) 
could  be  considered  in  the  model. 

-  Only  a  fixed  number  of  collection  subsystems  (a)  could 
be  considered  in  the  model. 

-  All  requirements  will  have  resources  allocated  toward 
their  satisfaction  at  the  same  time. 

With  these  assumptions  we  were  able  to  develop  a  series  of 
models  which  optimized  the  allocation  of  collection 
resources  for  a  giver,  set  of  collection  requirements.  The 
objective  of  this  chapter  is  to  illustrate  how  these  assump¬ 
tions  are  related  tc  the  realistic  collection  management 
environment  and  how  the  optimization  models  developed  in 
Chapter  five  can  easily  be  modified  to  adapt  to  such  an 
environment. 

E.  TEE  COLLECTION  HA1AGEME1T  ENVIRONMENT 

In  the  realistic  collection  management  environment 
collection  requirements  enter  the  system,  resources  which 
seem  suitable  are  tasked  toward  their  satisfaction  and  if 
the  requirements  are  satisfied  they  leave  the  system  (ether 
options  are  addressed  in  Chapter  Two)  .  Rarely,  if  ever,  are 
collection  requirements  viewed  in  groups  or  sets  as  our 
models  require.  A  uultiserver  queue  would  be  a  more  apt 
description  of  the  process. 
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Similarly,  collection  subsystems  are  rarely  considered 
as  a  set.  Either  a  subsystem  available  for  tasking  is  suit¬ 
able  (can  collect  what  the  requirement  indicates  is  neces¬ 
sary  to  collect)  for  satisfying  (or  at  least  partially)  a 
requirement  or  it  is  not.  If  the  subsystem  is  suitable  it 
is  tasked  and  if  it  is  not  suitable  it  is  not  tasked.  On 
occasion,  if  there  is  sufficient  justification,  additional 
collection  resources  may  be  requested  (and  perhaps  received) 
for  use  by  the  unit.  Similarly,  additional  (and  unplanned 
for)  collection  resources  will  sometimes  be  made  available 
by  a  higher  authority  for  use  by  the  unit’s  collection 
system. 

The  entire  allocation  process  is  affected  by  time 
constraints  associated  with  both  the  requirements  anc  the 
collection  subsystems  (see  Chapters  Three  and  Four) .  The 
hectic  pace  of  matching  requirements  with  suitable  and 
available  platforms  given  a  wide  variety  of  deadlines  rarely 
allows  fer  more  than  a  momentary  consideration  of  the  best 
allocation  for  a  set  cf  collection  requirements. 

It  appears,  therefore,  that  the  assumptions  we  made  in 
developing  the  optimization  models  counter  our  observations 
cf  the  realistic  collection  management  environment.  The 
next  section  of  this  Chapter  illustrates  how,  through  a  time 
analysis  of  all  collection  requirements  and  minor  modifica¬ 
tion  tc  the  structure  of  the  basic  model,  these  problems  can 
be  easily  overcome. 

C.  TIHE  OBEEHING  OF  COLLECTION  REQUIREMENTS 

If  our  models  are  to  be  useful  they  must  be  adapted  to 
the  collection  environment.  To  do  this  we  must  be  able  to 
identify,  from  the  environment,  those  requirements  which 
will  be  allocated  collection  resources.  We  know  that  the 
number  cf  requirements  in  our  imagined  queue  is  variable  and 


dependent  upon  a  variety  of  battlefield  conditions.  We  also 
know  that  the  requirement  queue  is  not  a  FIFO  (first  in 
first  out)  cr  a  LIFO  (last  in  first  out)  queue  but  some  sort 
of  a  mixed  queue.  lie  realize  that  we  are  more  concerned 
with  taskinq  resources  to  satisfy  requirements  whose  tasking 
deadlines  are  it  the  near  future  rather  than  those  whose 
deadlines  are  further  into  the  future.  At  the  same  time, 
however,  we  do  not  want  to  squander  our  resources  now 
without  consideration  for  future  requirements.  These  obser¬ 
vations  indicate  that  the  number  of  requirements  we  want  to 


consider  in 

dependent. 

the  our  requirement 

set 

is  somewhat  time 

This  time 

dependency  suggests 

that 

all 

intelligence 

requirements 

in  the  collection 

system 

can 

be  ordered 

according  tc 

some  time  parameter. 

The 

time 

parameter  of 

concern  is  what  has  previously  been  referred  to  as  a  tasking 
deadline.  Consider  a  single  collection  requirement  i  in  a 
collection  system  consisting  of  j  =  1, . . . ,m  collection 

subsystems.  This  requirement  would  have  associated  with  it 
various  time  restraints  (see  Chapters  Three  and  Fcur). 
Likewise,  each  collection  subsystem  would  have  associated 
with  its  resources  various  time  restraints.  If  the  time 
restraints  associated  with  collection  subsystem  j  were  to  be 
combined  with  the  time  restraints  associated  with  collection 
requirement  i  then  a  tasking  deadline  (t^)  cculd  be 
identified. 

t; =  Ihe  tasking  deadline  associated  with  requirement  i 
and  subsystem  j.  That  point  in  time  beyond  which 
subsystem  j  cannot  be  tasked  to  satisfy  require¬ 
ment  i. 

If  we  are  considering  a  total  of  m  subsystems  (all  of  wnich 
could  contribute  to  the  satisfaction  of  requirement  i)  and 
none  of  the  time  restraints  associated  with  those  subsystems 
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were  idertical  then  there  would  exist  a  maximum  of  m  tasking 
deadlines  associated  with  requirement  i.  We  are  concerned 
with  identifying  that  t;-  value  which,  if  met,  would  not 

~  j 

exclude  the  use  of  any  of  the  subsystems  which  can 
contritute  to  the  satisfaction  of  requirement  i  from  doing 
so.  That  value  will  he  referred  to  as  t^,,-  : 

tn;  =  The  latest  point  in  time  such  that  all  subsystems 
which  can  contribute  to  requirement  i  can  be 
tasked  to  do  so. 

or,  given  that  all  t.^  values  fall  along  the  interval  from 
t  3  0  to  t,  then  can  be  defined  in  the  following  manner: 

tc^  =  That  value  of  t^j  which  produces  the  minimum  value 
of  the  expression: 


(.  t .  .  «  tn  )  V  n 
n  n  - 


(eqn  6.1) 


Thus,  .  might  be  referred  to  as  a  global  tasking  deadline 
for  requirement  i. 

The  purpose  of  defining  t  ^  was  to  identify  a  reasonable 
means  cf  ordering  collection  requirements  according  to  time. 
The  tc£  values  can  easily  be  determined  for  each  collection 
requirement  in  the  collection  system.  Note  that  tc^  values 
are  entirely  dependent  upon  the  collection  subsystems  (their 
time  restraints)  available  for  tasking  by  the  collection 
system  (actual  and  envisioned).  In  the  event  additional 
(and  net  envisioned)  collection  subsystems  were  made  avail¬ 
able  to  the  collection  system  then  t  ^  values  could  easily 
be  recalculated. 
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We  are  still  faced  with  the  question  of  how  to  determine 
which  set  cf  re  guireirents  will  be  included  in  the  model. 

That  determination  will  be  based  upon  a  close  examination  cf 

the  time  ordered  set  of  requirements.  He  would  like  to 
include  all  requirements  in  the  model.  This,  however,  may 
be  unreasonable  if  the  range  of  t  .  values  is  great  (i.e. 
greater  than  12  hours).  This  is  primarily  due  tc  the  fact 
that  we  just  aren't  that  concerned  with  requirements  whose 
tasking  deadlines  are  far  into  the  future.  Requirements 

whose  t  .  values  fall  within  the  zero  to  eight  hour  range 
seem  mere  appropriate  for  inclusion  in  the  model.  This 

determination,  of  course,  could  change  accordirg  to  a 
variety  cf  possible  battlefield  conditions.  We  will  call 

this  time  range  cf  interest  t.  ,  where: 

int 

t  •  t=  That  time  interval  in  which  we  are  concerned  with 
tasking  collection  resources  toward  the  satisfac¬ 
tion  of  intelligence  requirements. 

The  requirements  which  fall  within  this  range  of  interest 
(t^nf)  constitute  a  subset  of  n  (the  total  number  of 
requirements  in  the  collection  system)  and  will  be  defined 
in  the  following  manner: 


n  =  The  time  ordered  subset  of  the  total  number  of 
collection  requirements  (n)  which  fall  within 
t  . 


Thus,  n  is  tha 
requirements  in 
short  run,  inte 
reduced  the  numb 
models  tc  those 
can  easily  be  mo 
n: 


t  subset  of  the  total  number  of  collect 
the  collection  system  which  we  are,  in 
rested  in  satisfying.  We  have,  therefo 
er  of  requirements  to  be  considered  in 
cf  mere  immediate  interest.  The  basic  mo 
dified  to  adjust  for  the  change  in  values 
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MAXIMIZE: 


SU3JECT  TO 


S  a .  .  d  . 

Z.  i]  i: 


d . .  =  C  or  1 


This  modification  can  be  applied  to  all  other  models 
developed  in  Chapter  Five. 

As  alluded  to  in  previous  discussion  n  is  primarily 

based  upon  the  determination  of  t.  The  range  of  t- 

int  3  intr 

however,  is  guite  subjective  and  variable.  Thus,  we  can 
look  upon  n  as  a  variable.  Se  have  shown  that  the  models 
developed  in  Chapter  Five  can  be  modified  to  include  n  and 
they  therefore  appear  to  be  useful  in  realistic  applications 
where  the  number  of  collection  requirements  under  considera¬ 
tion  is  variable.  Furthermore,  we  have,  by  time  ordering 
the  set  of  collection  requirements,  expressed  those  require¬ 
ments  as  a  function  of  time  -  the  first  step  toward  a  more 
realistic  piecewise  collection  resource  allocation  process. 

0.  A11CC ATING  COLLECTION  RESOURCES 


An  assumption  of  the  basic  model  was  that  all  collection 
requirements  under  consideration  will  have  collection 
resources  allocated  toward  their  satisfaction  at  the  same 


time.  An  examination  of  the  realistic  setting  clearly  indi¬ 
cates  that  this  assumption  is  unreasonable.  The  previous 
section  developed  a  requirement  scheduling  method  which 
would  help  the  decision  maker  determine  which  collection 
requirements  in  the  collection  system  the  optimization 
models  ought  to  include.  A  reasonable  approach  toward  allo¬ 
cating  collection  resources  is  to  allocate  (based  upon  the 
output  of  the  optimization  model)  only  to  those  requirements 
whose  tci  values  are  near,  update  the  model  with  respect  to 
current  conditions  (new  incoming  requirements,  modified 
amount  of  resources  available,  and  new  t  .  values)  ,  and 
optimize  over  the  new  set  of  conditions.  The  allocation 
process  would  lock  like  that  shown  in  Figure  6.1. 

This  allocation  process  allows  for  the  variation  of  the 
amount  of  collection  resources  considered  in  the  optimiza¬ 
tion  models  and  for  the  piecewise  allocation  cf  such 
resources  toward  the  satisfaction  of  collection  require¬ 
ments.  The  success  of  this  process,  however,  is  dependent 
upon  several  factors.  A  factor  of  primary  importance  is 
whether  or  not  the  optimization  model  employed  in  the 
process  can  provide  a  feasible  allocation  plan  in  a  timely 
manner.  Additionally,  we  are  assuming  that  necessary  inputs 
(updates  of  current  conditions)  can  be  provided  to  the 
process . 

It  is  important  to  note  that  the  models  can  be  applied 
to  situations  in  which  the  amount  of  available  resources  are 
variable  and  actual  resource  allocations  are  made  in  a 
piecewise  fashion.  This  is  accomplished  by  embedding  the 
optimization  model  in  an  iterative  allocation  process  rather 
than  through  any  modification  of  the  actual  model. 

The  optimization  models  developed  in  Chapter  Five  appear 
to  be  more  flexible  than  initially  envisioned.  They  can  be 
adapted  to  the  more  realistic  collection  management  setting 
in  which  both  requirements  and  resources  are  variable  and 


111 


focus  on  the  maneuver  division  in  estimating  the  size  cf  the 
various  components  of  the  collection  management  problem. 

The  collection  subsystems  available  to  a  division 
generally  fall  into  two  classes: 

-  orgaric:  Those  belonging  to  the  division. 

-  ncn-organic:  Those  which  the  division  can  (in  certain 

situations)  task  for  use  tut  do  not  own. 

Eivisions  are  virtually  free  to  operate  their  organic 
subsystems  (IMINT,  SIGINT,  and  HCJMINT)  in  accordance  with 
their  battlefield  role  or  mission.  However,  the  division 
will  he  granted  access  to  non-organic  subsystems  (which 
correspond  closely  tc  those  found  at  the  division  but  are 
usually  more  specialized)  only  when  its  battlefield  mission 
is  of  relative  importance  (i.e.  the  unit  is  in  contact  with 
enemy  forces).  Thus,  the  number  of  collection  subsystems 
available  tc  a  division  varies  (primarily  as  a  function  of 
its  battlefield  role)  from  an  organic  number  of  three  tc  a 
maximum  number  (both  organic  and  non-organic)  of  twelve. 
The  availability  of  both  organic  and  non-organic  collection 
subsystems  is  also  dependent  upon  environmental  and  opera¬ 
tional  factors  (primarily  weather  and  threat) .  These 
factors  would,  of  course,  reduce  the  total  number  of 
subsystems  available  to  the  division. 

An  intelligence  system  of  a  division  is  normally 
concerned  with  approximately  15  to  30  standing  intelligence 
requirements  (referred  to  as  Essential  Elements  of 
Information  and  Other  Intelligence  Requirements  -  EEI/OIR) 
and  perhaps  15  to  3C  user  generated  intelligence  require¬ 
ments.  Each  of  these  intelligence  requirements  are  vague 
and  can  be  decomposed  into  several  collection  requirements 
(i.e.  the  SIGINT  collection  subsystem  would  refer  to  these 
collection  requirements  as  SIGINT  Indicators).  The  number 
of  collection  requirements  in  the  collection  system  is  also 
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somewhat  dependent  upon  the  battlefield  role  and  disposition 
of  the  division.  Cne  would  expect  tnat  the  number  of 
requirements  would  increase  as  more  organic  forces  are 
brought  into  contact  with  the  enemy.  Given  a  particular 
battlefield  situation,  the  number  of  collection  requirements 
we  would  expect  to  encounter  would  fall  between  30  and  200. 

Given  this  discussion  it  is  possible  to  address  the 
range  of  the  collection  management  problem.  Estimates  of 
the  maximum  size  and  minimum  size  problems  can  easily  be 


TABLE  I 

Size  of  the  Collection  Management  Problem 

Levels 

Maximum  Minimum 


Regts  (r) 

25  C 

30 

Sutsjs  (s) 

12 

3 

provided:  The  implications  of  these  estimated  values  are 
interesting.  For  example,  in  the  discrete  decision  (basic) 
model  under  maximum  conditions  (n  =  250  and  m  =  12)  ,  there 


would  exist  3000  {250  x  12)  decision  variables  (d,.  in  the 


discrete  model,  xij  in  the  continuous  model)  to  consider. 
This  assumes,  of  course,  that  each  collection  subsystem  is 
capable  of  contributing  to  the  satisfaction  of  each  collec¬ 
tion  requirement.  The  point  to  be  nade  is  that  the 
complexity  of  the  problem  increases  dramatically 


as  more 


collection  subsystem  and  requirements  are  added  tc  the 
collection  system.  This  observation  highlights  the  need  for 
us  tc  consider  all  reasonable  methods  of  reducing  the 
complexity  cf  the  problem  (  such  as  the  reduction  of  the  set 
cf  requirements  n  tc  n  as  discussed  in  Section  C  cf  this 
Chapter) . 

F.  CCNCIOSICNS  AND  EFCCMMENDATIONS 

This  thesis  has  developed  a  structure  for  and  examined 
the  functions  of  a  generalized  intelligence  collection 
system.  Traditional  approaches  toward  the  management  of 
collection  requirements  (identified  in  the  study  as  the 
primary  focus  of  the  collection  system)  were  shown  to  be 
inefficient  and  less  controlled  than  desired.  It  was  also 
shown  that  with  minor  restructuring  of  some  functions  within 
the  collection  system  and  development  of  the  capability  to 
estimate  subsystem  operational  capability  components  (p.. 
and  f^.),  operations  research  techniques  could  be  applied  to 
a  simplified  version  of  the  collection  system  problem,  that 
being  the  allocation  of  scarce  collection  resources  toward 
the  satisfaction  of  collection  requirements. 

A  mathematical  optimization  model  of  this  simplified 
process  was  developed.  Modifications  of  this  model  were 
explored  with  respect  to  important  intelligence  collection 
related  concepts  such  as  priority  of  requirements,  redundant 
collection  coverage,  and  applicability  of  the  optimization 
model  to  various  types  of  collection  subsystems. 

Future  efforts  in  this  area  should  focus  on  the 
following  tcpics: 

-  Solution  algorithms  to  the  models  developed  in  Chapter 
Five. 


-  Dse  cf  the  models  as  decision  aids  in  wargames  and  as 
resource  allocation  algorithms  in  battlefield  simula¬ 
tions. 
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A£PENDIX  A 

A  HETHOD  OF  HANKING  COLLECTION  REQUIREMENTS 

Collection  systems  have  traditionally  prioritized 
collection  requirements  according  to  SOP's.  Each  unit's  SO? 
is  different  from  another.  They  all,  however,  prescribe 
what  a  requirement  priority  will  be  given  the  existance  of 
certain  conditions  on  the  battlefield.  For  example,  an  SOP 
may  require  that  collection  requirements  from  support  units 
(non-combat  forces)  cannot  be  submitted  as  high  priority 
requirements.  The  battlefield  condition  in  this  example  is 
the  nature  of  the  friendly  unit  submitting  the  requirement. 

Collection  requirements  are  rarely  analyzed  in  groups. 
Thus,  orce  a  requirement  {and  its  priority  as  determined  by 
the  SCP)  are  validated  (approved  by  the  collection  system 
decisicn  maker)  they  are  forwarded  for  action  to  the 
collection  subsystems.  In  the  restructured  approach 
Xscussed  in  this  thesis  a  set  of  collection  requirements 
are  decomposed  at  the  system  level  prior  to  being  forwarded 
to  the  collection  subsystems  for  action.  Thus,  it  is 
feasible  at  the  system  level  to  analyze  a  set  of  require¬ 
ments  with  respect  to  priority.  Specifically,  it  is 
possible  to  re-prioritize  this  set  of  collection  require¬ 
ments  with  respect  to  the  current  battlefield  conditions 
rather  than  those  which  may  have  existed  when  the  collection 
requirement  was  initially  submitted  for  satisfaction  by  the 
user . 

This  approach  recognizes  the  fact  that  battlefield 
conditions  change  and  that  the  relative  importance  of  one 
requirement  with  respect  to  another  might  also  change.  In 
this  study  the  battlefield  conditions  previously  addressed 
will  be  referred  to  as  battlefield  parameters  of  interest  or 
simply  parameters. 
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The  objective  or  this  process  is  to  rank  all  require¬ 
ments  under  consideration  based  upon  one  or  several  of  the 
battlefield  parameters  of  interest.  In  effect,  this  process 
provides  the  decision  maker  with  a  method  of  prioritizing 
requirements  in  accordance  with  the  current  or  projected 
battlefield  conditions.  A  multi-criteria  aggregation  scheme 
will  be  used  to  rank  the  set  of  collection  requirements. 

A.  TEE  EECOIBEHENT  E ASKING  MODEL 

The  mcdel  for  the  requirement  ranking  process  is 
described  below: 


MAXIMIZE: 


I  “k?ari: 


k  =  1 


(egn  A.1) 


i  =  The  index  fcr  requirements. 


k  =  The  index  fcr  parameters. 


1  =  The  total  number  of  battlefield  parameters. 


w ,  =  Weighting  associated  with  the  kth  parameter. 


par^k=  The  kth  battlefield  parameter  associated  with  the 
ith  requirement. 

There  are  a  number  of  ways  in  which  this  scheme  can  be 
implemented  through  the  specific  allocation  of  weights  tc  a 
particular  set  of  parameters. 


E 


EATTIEF3ELD  EARAHETERS 


Four  general  oattlefield  parameters  of  interest,  will  re 
addressed  in  this  study.  These  four  categories  of  parame¬ 
ters  are  net  all  inclusive.  Virtually  any  parameter  of 
interest  to  the  unit  cr  command  (depending  upon  the  require¬ 
ment  structure)  could  easily  he  substituted  for  or  added  to 
those  addressed  in  the  study.  These  are,  however,  represen¬ 
tative  cf  the  basic  concerns  of  battlefield  decision  makers. 

The  first  parameter  addressed  is  the  actual  priority 
attached  to  the  requirement.  The  requirement  priority  is 
provided  by  the  user  when  it  is  initially  submitted  into  the 
collection  system  for  satisfaction.  It  will  be  assumed  that 
priority  reflects  tbe  importance  of  a  requirement  tc  the 
user  with  respect  to  all  other  collection  requirements 
submitted  in  accordance  with  the  priority  system  (abuses  of 
priority  systems  will  not  be  addressed).  For  example,  it 
will  be  assumed  that  all  high  priority  requirements  are  of 
greater  relative  importance  to  all  users  than  all  medium 
priority  requirements,  etc.  There  are  many  different  types 
cf  priority  systems  in  use.  Host  of  these  systems  attempt 
to  classify  items  in  terms  of  levels  of  importance 
(priority).  Such  classific ation  schemes  can,  in  themselves, 
become  complex.  Only  three  levels  of  priority  will  be 
considered  in  this  study  -  high,  medium,  and  low. 

The  friendly  unit  submitting  the  requirement  is  the 
second  parameter  of  interest.  As  the  battlefield  changes, 
so  dees  the  relative  importance  of  friendly  units.  This 
importance  is  reflected  in  the  amount  of  support  a  command 
receives  from  its  parent  and  supporting  units.  This 
includes  intelligence  collection  support.  It  is  therefore 
important  tc  be  able  to  reflect  this  changing  importance 
when  ranking  collection  requirements.  The  number  and  type 
of  units  included  as  varieties  of  this  parameter  are,  of 


coarse,  dependent  upon  the  organization  operating  the 
collection  system.  A  Corps,  for  example,  may  want  to 
include  its  covering  force,  major  maneuver  divisions,  and 
artillery  forces  in  this  category  of  parameters.  This  study 
will  focus  at  the  Division  level  and  will,  therefore, 
include  as  its  friendly  units  of  interest  the  primary  users 
of  its  collection  system  -  two  maneuver  units  (number  1  and 
number  2),  an  artillery  unit,  and  a  headquarters  element. 

The  area  of  the  battlefield  in  which  the  requirement  is 
focused  is  the  third  parameter  or  interest.  The  identifica¬ 
tion  of  where  the  enemy  may  be  attacking  from  is  a  tradi¬ 
tional  concern  to  the  military  decision  maker.  Thus,  the 
ability  to  control  collection  with  respect  to  battlefield 
area  is  cne  method  of  coping  with  this  concern.  This  param¬ 
eter  is  iritially  provided  by  the  user  when  submitting  the 
collection  requirement.  However,  between  requirement 
submission  and  the  collection  allocation  decision  there  is  a 
possibility  that  this  parameter  might  change.  For  example, 
an  enemy  unit  originally  located  in  the  rear  area  of  the 
battlefield  may  have  moved  forward  by  the  time  a  collection 
requirement  concerning  that  unit  can  be  acted  upon.  Thus, 
the  status  of  this  parameter  should  be  updated  by  the  system 
operators  prior  to  the  collection  allocation  decision.  Fcur 
battlefield  areas  will  be  used  in  this  report  (see  Figure 
A.  1 )  .  Areas  I  and  II  represent  those  areas  in  contact  with 
friendly  forces  (FLOT  stands  for  the  front  line  of  troops) 
while  areas  III  and  17  represent  the  enemy  rear  areas. 
Traditionally,  fighting  units  are  primarily  concerned  with 
threats  in  the  forward  areas  I  and  II.  Headquarters 
elements  and  interdiction  forces  are  more  interested  in 
targets  and  enemy  activities  in  the  rear  areas  III  and  IV. 

Enemy  activity  is  the  last  battlefield  parameter  of 
interest  to  be  considered.  Different  battlefield  users  of 
the  collection  system  are  concerned  with  different  forms  of 
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Figure  1.1  Battlefield  Areas. 

enemy  activity.  Maneuver  units  tend  to  be  concerned  with 
enemy  maneuver  and  artillery  forces,  support  units  with 
special  operation  forces,  headquarters  elements  with  inter¬ 
diction  targets  and  command  and  control  operations.  These 
concerns,  of  course,  vary  as  the  battlefield  situation 
varies.  Thus,  timely  control  of  the  type  of  enemy  activity 
the  collection  effort  is  directed  against  is  valuable.  For 
illustrative  purposes  the  study  considers  four  such  classes 
of  enemy  activity  -  maneuver  forces,  artillery  forces, 
support  forces,  and  C3/other  forces.  Table  II  summarizes 
the  xajcr  classes,  levels,  and  subclasses  of  the  fifteen 
parameters  mentioned. 

C.  E ATTIEFIELD  PABABETER  VALUES 

In  this  scheme  two  of  the  classes  of  parameters  associated 
with  a  given  requirement  have  no  particular  values  associ¬ 
ated  with  them  other  than  presence  or  absence  (with  associ¬ 
ated  values  of  either  one  or  zero).  For  instance,  a 
requirement  can  have  either  a  high,  medium,  or  low  priority. 


TABLE  II 

levels  and  Classes  cf  Bequirement  Parameters 


CLASS 


IEVEL  SUBCLASS 


Priority  High 

Medium 

Low 

Friendly  User  Manuever  Unit  1 

Maneuver  Unit  2 
Artillery  Unit 
Headguarters  Element 

Battlefield  Area  I 

II 

III 

IV 


Enemy  Activity 


Maneuver 
Artillery 
Support  F 
C3/other 


Forces 

Forces 

orces 

Forces 


This  characteristic  is  also  valid  with  respect  to  the 
friendly  unit  submitting  the  requirement.  It  does  not 
necessarily  apply  to  the  parameter  classes  of  battlefield 
area  or  type  of  enemy  activity.  It  is  conceivable  in  these 
cases  that  varying  degrees  of  values  could  be  associated 
with  more  than  one  parameter  of  the  class.  For  instance,  a 
requirement  regarding  the  communications  capability  cf  an 
enemy  artillery  unit  would  fall  into  both  the  C3  and 
artillery  parameter  classes.  Likewise,  a  requirement  could 
easily  be  associated  with  more  than  one  area  of  the 
battlefield.  These  sorts  cf  evaluations  would  be  provided 
by  the  user  and  perhaps  modified  by  the  collection  system 
operator  with  the  aid  of  standard  operating  procedures. 


WEIGHTING  OF  BATTLEFIELD  EABAHETERS 


I 


D. 


TABLE  III 

Requirement  Parameter  Weighting  Schemes 


PAFAMETEF  I 

Priority  (h)  .5 

Priority  Cm)  .3 

Priority  (1)  .2 


Onit  1 
Unit  2 
Arty  Unit 
HC  Element 

Area  I 
Area  II 
Area  III 
Area  IV 

Maneuver  Force 
Arty  Force 
Support  Force 
C3/Ct her 


WEIGHTING  SCHEMES 

II  III  IV 

.2 


.3 

.3 

.2 

.2 

.2 

.2 

.2 

.3 

.3 

.3 

.3 


Tafcle  III  illustrates  several  battlefield  parameter 
weighting  schemes.  Weighting  scheme  number  I  can  be 
referred  to  as  a  standard  scheme.  The  ranking  of  require¬ 
ments  using  this  scheme  is  based  solely  upon  the  priority  of 
the  submitted  requirements.  Scheme  number  II  can  be 
referred  to  as  a  support  scheme.  Collection  requirements 
will  be  ranked  based  upon  the  friendly  unit  submitting  the 
requirement  with  seme  emphasis  placed  upon  priority. 
Specifically,  maneuver  unit  number  one  and  the  artillery 


unit  are  favored  over  the  neaacuarters  element.  The  HQ  is, 
in  turn,  weighted  equally  with  high  priority  r eguiremer ts. 
The  purpose  behind  this  sort  of  weighting  scheme  would  be  to 
provide  collection  support  to  specific  units  because  of 
their  importance  in  relation  to  the  current  or  projected 
battlefield  situation. 

The  last  two  weighting  schemes  are  oriented  towards 
targeting.  Scheme  III,  for  instance,  is  weighted  to  support 
requirements  concerning  enemy  combat  force  targets  (maneuver 
and  artillery  forces)  near  friendly  forces  (in  battlefield 
areas  I  and  II) .  This  scheme  could  be  referred  to  as  a 
direct  support  targeting  scheme.  Scheme  17,  on  the  ether 
hand,  is  oriented  towards  targets  in  the  enemy  rear  area 
(battlefield  areas  III  and  IV)  and  of  a  soft  nature  (C3  and 
Support  Elements).  This  scheme  could  be  referred  to  as  an 
interdiction  targeting  scheme.  If  the  decision  maker  were 
interested  only  in  enemy  artillery  forces  in  battlefield 
area  II  then  only  these  two  parameters  should  be  weighted 
(.5  in  each  case  because  there  are  two  parameters  of 
interest).  If  there  exist  such  targets  in  the  requirement 
set  then  they  will  be  the  highest  ranking  targets  in  the 
ordered  requirement  vector. 

The  quantity,  variety,  and  resolution  levels  of  possible 
weighting  schemes  are  uncountable.  This  methodology  would 
be  particularly  useful  to  the  decision  maker  in  the  event  he 
was  required  to  rank  a  large  number  of  collection  require¬ 
ments. 

E.  AS  EXAMPLE  USING  THE  REQUIREMENT  RANKING  MODEL 

Table  IV  presents  a  set  of  twenty  sample  collection 
requirements  which  were  generated  to  demonstrate  the  multi- 
criteria  approach  to  collection  requirement  ranking.  Note 
that  in  Table  IV  the  values  for  the  first  two  groups  of 


parameters  (priority  and  friendly  unit)  are  merely  a  one  or 
and  dash.  The  cne  signifies  a  yes  and  the  dash  sigrifies  a 
no.  Ir  ether  words  require  Bent  number  1  has  a  high  priority 
and  was  submitted  by  the  friendly  artillery  unit. 

The  values  associated  with  the  second  two  groups  of 
parameters  (battlefield  area  and  enemy  activity)  are 
expressed  as  percentages.  Requirement  number  one,  there¬ 
fore,  is  concerned  with  enemy  combat  and  artillery  forces 
in  the  forward  two  areas  of  the  battlefield  (Areas  I  and 
II)  . 

Much  of  this  infermatien  is  provided  by  the  user  when 
submitting  a  requirement  for  satisfaction.  Traditionally, 
however  it  has  been  forwarded  in  subjective  rather  than 
numerical  form.  Thus,  the  success  of  this  sort  of  a  priori¬ 
tization  scheme  would  be  contingent  upon  the  ability  of  the 
battlefield  to  satisfactorily  estimate  the  appropriate 
parameters  in  a  numerical  manner. 
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TABLE  IV 

Saaple  Collection  Requirements 
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These  requirements  were  placed  into  an  A?L  usafcle  format 
using  the  program  REAEREQ.  This  is  an  interactive  program 
which  queries  the  operator  for  a  collection  requirement 
vector  (figure  A. 2) .  The  input  values  for  this  vector  are 
shown  at  Tatle  7. 


v  oifREADREa;v;vi;RHO(s 
Cl  3  vi«-  1  16  ro 

C23  ONE* 'ENTER  COMPONENT  REQUIREMENT  VECTOR • 

C  3  3  V«-Q 

[43  V1«-V1,C13  v 

C53  RM«-vi 

C63  'FINISHED?  (YES/NO)*' 

C  7  3  S«-Q 

C83  -»stopx»3=+/' tES'=3fs 

CV  3  -(ONE 

C 103  stop; 

C  1 1  3  Rmoh  lf(fRM)  )-i 
C  1 23  rm«.(rho,ia)/-(1AI,RH) 

C  1 33  «1«-RM 


Figure  A. 2  Beguirement  Input  Program  READBEv). 


READBEC  formats  the  n  collection  requirements  in  matrix  form 
which  can  be  operated  upon  by  the  APL  program  ICAIC.  ICALC 
uses  the  mcdel  addressed  previously  to  rank  the  requirements 
which  were  submitted  by  the  operator  using  RSADREQ.  The 
output  of  ICALC  is  the  a  rank  ordered  requirement  vector. 

Tatle  VI  illustrates  how  the  weighting  schemes  discussed 
in  an  earlier  portion  of  this  appendix  rank  the  set  of 
sample  requirements  presented  at  Table  IV.  Note  the 

requirement  order  for  Scheme  I  (recall  that  this  was 
referred  to  as  the  standard  scheme  which  basically  ranks 
requirements  according  the  their  user  provided  priority) . 
The  first  eight  requirements  in  Scheme  I  (1  through  18)  are 


TABLE  T 

EEADREQ  Entry  Data 


Vector 

Element 

Compon  ent 

Value 

Format 

1 

Requirement  Number 

1 

to 

20 

2 

Priority  (High) 

0 

or 

1 

3 

Priority  (Medium) 

0 

or 

1 

4 

Priority  (low) 

0 

or 

1 

5 

Friendly  Onit  I 

0 

or 

1 

6 

Friendly  Onit  II 

0 

or 

1 

7 

Artillery  Onit 

0 

or 

1 

8 

Headquarters  Element 

0 

or 

1 

9 

Battlefield  Area  I 

0 

to 

1 

10 

Battlefield  Area  II 

0 

to 

1 

11 

Battlefield  Area  III 

0 

to 

1 

12 

Battlefield  Area  IV 

0 

to 

1 

13 

Enemy  Maneuver  Force 

0 

to 

1 

14 

Enemy  Artillery  Force 

0 

to 

1 

15 

Enemy  Support  Force 

0 

to 

1 

16 

Enemy  C3/Other  Force 

0 

to 

1 

the  same  requirements  which  Ta-ble  IV  indicates  have  a 
priority  cf  one.  The  next  eight  requirements  (3  to  19)  have 
a  priority  cf  two  aid  the  last  four  (5  through  20)  hav<_  a 
priority  of  three.  In  Scheme  II  the  requirement  crder  is 
based  upon  the  unit  submitting  the  requirement  and  the 
priority.  A  look  at  the  higher  ranking  requirements  associ¬ 
ated  with  Scheme  II  does  indicate  that  they  are  a  function 
cf  being  high  priority  and/or  from  Onit  1f  the  artillery 


^  ICftLC  J  RHO  J  N ; W  j  WM  j  XBfiR } XM } 5DM } XRM } NXRM } SXRM 
C1D  RHO»-f  (RM) 

C23  N«-20 

[Tj  j  •  ENTER  16  COMPONENT  WEIGHT  VECTOR* 

C43 

C53  rW«-16P<-^16) 

C63  WMf(RHO)fW 

C73  XBORf  (  +/RM)  -fN 

C83  XM«-(RHO)fXMR 

C93  NRMf  O  1  l(WMXRM) 

CIOD  5XRMf +/XRM 

C113  n:<rm«-$(2  20  )  f  <  <  \  N  >  »  <  »  sxrm  )  ) 

C123  OREOf HXRM[fNNRM[  f 2]  *  3 

C131  *  REQUIREMENT  RANKING* 

C14D  RRfOREQ[  $  1 ] 

C  153 

C1A3  OMXfflMjNXRM[ 523 

C  173  AMxn  J23*-AMXC  »23x«MXC  »33 

C183  J53«-AMXC  »53xOM;<C  i  63 

C193  amxc  ;  83«-AMXC  »  83  x«mxc  J  93 
£  20  3  flMX«-AKX[t*HX[  1 1 1  3  t  3 


Figure  A. 3  Multi-Criteria  fieguirement  Hanking  Prcgraa. 

Schemes  III  and  IV  reveals  that  they  ic  indeed  rank  the 
given  set  cf  collection  requirements  in  the  manner  suggested 
ty  their  respective  weighting  schemes.  Specifically,  Scheme 
III  is  oriented  towards  enemy  combat  arms  forces  in  the 
forward  areas  of  the  battlefield  and  Scheme  IV  is  oriented 
towards  support  and  C3  forces  located  in  the  rear  areas  of 
the  tattiefield. 

Cce  additiocal  point  for  con  -  ra  tion  regards  the 
complexity  of  tne  requirement  weighting  schemes.  This  xodel 
will  rank  collection  cegiiremerts  according  to  even  the  most 
intricate  of  weighting  schemes.  It  is  difficult,  however, 
to  understand  the  output  of  sicn  complicated  schemes. 
Simple  schemes  are  easy  to  checx  and  also  useful  in  sorting 
out  a  difficult  collection  management  problem.  This  portion 
of  the  xodel  is  presented  as  a  decision  aid  to  allcw  for 
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acquirement  FanJcing  with  Weighting  Schemes 
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